Re: SysV shutdown hanging

[Justus Winter]

Hi Thomas :)

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.

I see however some process crashing, and the crash server failing
hard:

Thread 1 (Thread 4931.1):
#0  0x010b1a4c in mach_msg_trap ()
    at /usr/src/glibc-2.19/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
#1  0x010b222e in __mach_msg (msg=msg@entry=0x1604920, option=option@entry=3, 
    send_size=send_size@entry=48, rcv_size=rcv_size@entry=32, rcv_name=65, 
    timeout=timeout@entry=0, notify=notify@entry=0) at msg.c:110
#2  0x0127a889 in __msg_sig_post (process=11, signal=6, 
    sigcode=sigcode@entry=0, refport=1)
---Type <return> to continue, or q <return> to quit---
    at /usr/src/glibc-2.19/build-tree/hurd-i386-libc/hurd/RPC_msg_sig_post.c:143
#3  0x010f04a9 in kill_port (refport=<optimized out>, msgport=<optimized out>)
    at ../sysdeps/mach/hurd/kill.c:67
#4  kill_pid (pid=pid@entry=4931) at ../sysdeps/mach/hurd/kill.c:104
#5  0x010f0761 in __kill (pid=4931, sig=sig@entry=6)
    at ../sysdeps/mach/hurd/kill.c:138
#6  0x010efb94 in raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#7  0x010f2116 in abort () at abort.c:89
#8  0x0112d05c in __libc_message (do_abort=do_abort@entry=2, 
    fmt=fmt@entry=0x1210082 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:175
#9  0x011d44e0 in __fortify_fail (
    msg=msg@entry=0x121006a "stack smashing detected") at fortify_fail.c:31
#10 0x011d449a in __stack_chk_fail () at stack_chk_fail.c:28
#11 0x0804be88 in dump_core (task=2, signo=1410542606, sigcode=650000, 
    sigerror=0) at ../../exec/elfcore.c:566
#12 0x00000019 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Curious, does your /servers/crash point to crash-dump-core as well?
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.

Cheers,
Justus

signature.asc
Description: signature