Hi Justus! On Fri, 12 Sep 2014 21:06:30 +0200, Justus Winter <4winter@informatik.uni-hamburg.de> wrote: > Quoting Thomas Schwinge (2014-09-12 09:16:32) > > In my QEMU Debian GNU/Hurd instance, I do some stuff (GDB testsuite, for > > example), and then issue a »sudo shutdown -r now«. This doesn't > > complete, but hangs like this: > > > > PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args > > [...] > > 28386 0 1 28386 28386 2 147M 1.67M 0.0 0:00.00 0:00.01 /bin/sh /etc/init.d/rc 6 > > 28391 0 28386 28386 28386 2 146M 1000K 0.0 0:00.01 0:00.00 /lib/startpar/startpar -p 4 -t 20 -T 3 -M stop -P 2 -R 6 > > 28413 0 28391 28386 28386 2 147M 1.72M 0.0 0:00.00 0:00.00 /bin/sh /etc/init.d/sendsigs stop > > 28418 0 28413 28386 28386 2 146M 668K 0.0 0:00.00 0:00.00 sync > > [...] > > > > The sync is hanging; confirmed with a manually run »syncfs -s« which also > > hangs. > > Right, I also see this. > > > What seems suspicious is the following: > > > > 814 0 5 1 1 15 141M 984K 99.8 0:00.23 11:47.19 /hurd/console > > > > ..., and indeed if I »kill -KILL« that one, some time later (?), the > > shutdown proceeds. > > My /hurd/console isn't chewing CPU time, though I see the kernel > complaining about it deallocating an invalid port. I'll see if I can > track this down. Yes, I've also seen that one. > I see however some process crashing, and the crash server failing > hard: [...] > Curious, does your /servers/crash point to crash-dump-core as well? Nope; that system is set to use crash-kill. > Killing the crash server I managed to get my shutdown process going > again, though it got stuck again. Using the kernel debugger (at this > point, sysvinit succesfully killed all my shells) I could see that > indeed another crash server has been spawned. I killed all crash servers (the three variants), but that didn't have any effect; killing the CPU time eating console process however, the shutdown proceeded. Grüße, Thomas
Attachment:
pgpb18JeQoZ2T.pgp
Description: PGP signature