[Aptitude-devel] Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

[Manuel A. Fernandez Montecelo]

2015-09-20 12:55 GMT+01:00 Vincent Lefevre <vincent at vinc17.net>:
> On 2015-09-20 12:04:48 +0100, Manuel A. Fernandez Montecelo wrote:
>> 2015-09-20 2:08 GMT+01:00 Vincent Lefevre <vincent at vinc17.net>:
>> > On 2015-09-20 02:50:45 +0200, Vincent Lefevre wrote:
>> >> > >zira:~> pstree -ap 29204
>> >> > >bash,29204
>> >> > > └─aptitude,29206
>> >> > >     ├─(dpkg,29277)
>> >> > >     ├─dpkg,30424 --status-fd 76 --configure geoclue-2.0:amd64 ...
>> >> > >     │   └─sh,30438 -c...
>> >> > >     │       └─less,30440 -Lis
>> >> > >     └─{aptitude},29491
>> >>
>> >> There was a zombie dpkg process that was a child of aptitude.
>> >> Where did it come from?
>>
>> There are dpkg processes launched to e.g. ascertain whether multi-arch
>> is supported, and if it needs to use the arch when calling dpkg and
>> apt.  It is also called directly to reconfigre packages, but I assume
>> that you didn't issue that action.
>
> No, I didn't. But why would it leave a zombie?

No idea.  Unless it is an easily explainable thing (like waiting for
other children, somehow detached from that tree) that usually
indicates problems in the OS, e.g. failing disk driver.  Maybe simply
is related to the active dpkg process, just not painted as parent.


>> If we could see the arguments, mayge we would get better clues.  If
>> you can reproduce it in the future, please try to list the args of the
>> commands, if they are retrievable.
>
> The -p option shows the arguments: you can see this for the other
> processes. Unfortunately, as the dpkg was a zombie, the arguments
> were no longer available.

Can be in /proc/PID/cmdline, but I guess that if pstree doesn't say is
because this is not present anymore (that's why I added "if it's
retrievable").

-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>