I let the thing run, in case you came back by mail on IRC, and when I
looked at it again, the situation was different: no more CPU eater,
but "frontend" had spawned another itself, and it looks like the 3
processes are happily waiting, supposedly for each other:
# ps l 9079 27444 9092
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 0 9079 9078 20 0 36660 34272 pipe_w S+ pts/9 40:28
/usr/bin/perl -w /usr/share/debconf/frontend /usr/bin/ucf
/usr/share/bash/bash_completion /etc/bash_completion
0 0 9092 9079 20 0 10820 8156 pipe_w S+ pts/9 0:01 /bin/bash
/usr/bin/ucf /usr/share/bash/bash_completion /etc/bash_completion
1 0 27444 9079 20 0 39996 37096 pipe_w S+ pts/9 0:00
/usr/bin/perl -w /usr/share/debconf/frontend /usr/bin/ucf
/usr/share/bash/bash_completion /etc/bash_completion
strace may help understanding the interactions:
# strace -p 9079
Process 9079 attached - interrupt to quit
read(10, <unfinished ...>
Process 9079 detached
# strace -p 9092
Process 9092 attached - interrupt to quit
read(0, <unfinished ...>
Process 9092 detached
# strace -p 27444
Process 27444 attached - interrupt to quit
write(2, "COMPREPLY=( $( compgen -W \'${\n $"..., 4096 <unfinished ...>
Process 27444 detached
Looking at open files I see the following, which I suspect could
reveal that some unused fd's have not been closed after fork - not
that I claim it has anything to do with the current issue, but having
less of them could help seeing what's going on.
>From this it looks like the parent frontend is waiting for data from
the child frontend, while the latter tries to write to its parent.At
least this seems to explain why the load has dropped :)
# for i in 9079 9092 27444; do ll /proc/$i/fd;done
total 0
lrwx------ 1 root root 64 Mar 1 15:28 1 -> /dev/pts/9
lr-x------ 1 root root 64 Mar 1 15:28 10 -> pipe:[61623310]
lr-x------ 1 root root 64 Mar 1 15:28 12 -> pipe:[61623311]
lrwx------ 1 root root 64 Mar 1 15:23 2 -> /dev/pts/9
lrwx------ 1 root root 64 Mar 1 15:28 3 -> /dev/pts/9
l-wx------ 1 root root 64 Mar 1 15:28 32 -> pipe:[59344842]
lr-x------ 1 root root 64 Mar 1 15:28 4 -> /var/cache/debconf/config.dat
lr-x------ 1 root root 64 Mar 1 15:28 5 -> /var/cache/debconf/passwords.dat
lr-x------ 1 root root 64 Mar 1 15:28 6 -> /var/cache/debconf/templates.dat
l-wx------ 1 root root 64 Mar 1 15:28 7 -> pipe:[59345337]
lr-x------ 1 root root 64 Mar 1 15:28 8 -> pipe:[59345338]
lrwx------ 1 root root 64 Mar 1 15:28 9 -> /dev/pts/9
total 0
lr-x------ 1 root root 64 Mar 1 15:28 0 -> pipe:[59345337]
lrwx------ 1 root root 64 Mar 1 15:28 1 -> /dev/pts/9
lrwx------ 1 root root 64 Mar 1 15:23 2 -> /dev/pts/9
lr-x------ 1 root root 64 Mar 1 15:28 255 -> /usr/bin/ucf
l-wx------ 1 root root 64 Mar 1 15:28 3 -> pipe:[59345338]
l-wx------ 1 root root 64 Mar 1 15:28 32 -> pipe:[59344842]
total 0
lrwx------ 1 root root 64 Mar 1 15:28 0 -> /dev/pts/9
lrwx------ 1 root root 64 Mar 1 15:28 1 -> /dev/pts/9
lr-x------ 1 root root 64 Mar 1 15:28 10 -> pipe:[61623310]
l-wx------ 1 root root 64 Mar 1 15:28 11 -> pipe:[61623310]
l-wx------ 1 root root 64 Mar 1 15:28 13 -> pipe:[61623311]
l-wx------ 1 root root 64 Mar 1 15:23 2 -> pipe:[61623311]
lrwx------ 1 root root 64 Mar 1 15:28 3 -> /dev/pts/9
l-wx------ 1 root root 64 Mar 1 15:28 32 -> pipe:[59344842]
lr-x------ 1 root root 64 Mar 1 15:28 4 -> /var/cache/debconf/config.dat
lr-x------ 1 root root 64 Mar 1 15:28 5 -> /var/cache/debconf/passwords.dat
lr-x------ 1 root root 64 Mar 1 15:28 6 -> /var/cache/debconf/templates.dat
l-wx------ 1 root root 64 Mar 1 15:28 7 -> pipe:[59345337]
lr-x------ 1 root root 64 Mar 1 15:28 8 -> pipe:[59345338]
lrwx------ 1 root root 64 Mar 1 15:28 9 -> /dev/pts/9
Killing the child frontend interrupts dpkg configuration, and
rerunning the sdiff thing lets stace show, while at 95% CPU:
- ucf waiting for data on fd 0
- frontend looping doing the same set of brk's:
brk(0x93ff000) = 0x93ff000
brk(0x9451000) = 0x9451000
brk(0x94a3000) = 0x94a3000
brk(0x93ff000) = 0x93ff000
brk(0x9451000) = 0x9451000
brk(0x94a3000) = 0x94a3000
brk(0x93ff000) = 0x93ff000
brk(0x9451000) = 0x9451000
brk(0x94a3000) = 0x94a3000
brk(0x93ff000) = 0x93ff000
brk(0x9451000) = 0x9451000
brk(0x94a3000) = 0x94a3000
reattaching a bit later, the brk's have slightly changed:
brk(0x9451000) = 0x9451000
brk(0x94a1000) = 0x94a1000
brk(0x9401000) = 0x9401000
brk(0x9451000) = 0x9451000
brk(0x94a1000) = 0x94a1000
brk(0x9401000) = 0x9401000
Hope this helps. At least it would look like the problem would rather
be on debconf side.
best regards,
--
Yann
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
