On Sat, Nov 25, 2006 at 14:10:28 -0500, Carl Brown wrote:
> On Saturday 25 November 2006 11:16 am, Florian Kulzer wrote:
> > (There was a similar case on debian-kde a while ago and it turned out
> > that discover was hanging.)
>
> It is indeed discover that is hanging. The last line on stdout at the hang is:
>
> +++ discover --disable=serial,parallel,usb,ide,scsi '--format=%V
> %M\t%S\t%D\n' video
>
>
> discover version is 1.7.19.
> The hang is easily reproduced by running the above discover command.
>
> Hmmm... it seems that all previous attempts left discover threads open.
> Now I have six discover pid's that root can't kill,
> and the root shell that I ran the command on is hung.
>
> Any suggestions?
How did you try to kill the discover processes? The default for kill is
to send SIGTERM which does not work if the process in question is really
hung. "kill -9 <pid>", on the other hand, should work or "pkill -9
discover" if you want to kill them all with one fell blow. (This will
kill all processes with "discover" in their name, so there might be some
unintended additional casualties.)
If you cannot "kill -9" a process as root then something has gone
seriously wrong at kernel level and it might be better to reboot at the
next opportunity.
Once the zombie processes have been killed you can try to uninstall
discover with "dpkg --remove discover" and check if that unblocks the
xserver-xorg postinst script. AFAIK, discover is not really needed if
you have a working xorg.conf already and the script should just skip
this step if it does not find discover on your system. If you ever need
hardware detection again then you can try if the "discover1" package
works better. (That was the case for the user on debian-kde.)
--
Regards,
Florian
