Killall5 indeed is hanging.  Here is what is going on:

/etc/init.d/sendsigs invoked during Ubuntu shutdown spoils the fun.  Using
strace I have determined that the killall5 -TERM -o <ZFS pid> hangs the
machine because it first kill()'s -STOP the -1 PID (that is, all PIDs),
which obviously causes zfs-fuse to stop.  That is the extent of what I could
find out, because strace itself is -STOPped in this situation, and I cannot
obtain any further traces.

How can I immunize a process against SIGSTOP?  There is no way in POSIX to
do so, so what is the reasonable workaround?

OK, so what does killall5.c do?  It first SIGSTOPs everything.  Then it
runs readproc() routine whose purpose is to figure out which processes
there are.  SIGSTOP makes lots of sense if you want to have a stable system
go down in an orderly fashion, but it fails with zfs-fuse because zfs-fuse
STOPs, and then readproc() attempts to stat binaries in ZFS filesystems...
and you know where that leads - system hung().

Chicken and egg.

Fortunately, I have a patch.  Attached is a new version of the
killall5.c file for the package, that does the right thing, by early-
CONT'ing the omitted processes.  I would have uploaded a debdiff but
debdiff just fails (that thing is a hack).

This should let everyone have ntfs-3g as root filesystem with no
concerns whatsoever.  The only caveat is, the file blindly goes through
all the arguments with atoi() instead of properly parsing them with
getopt, but hey, I'm not the genius who interspersed getopt parsing with
the pidof functionality, so thank you very much this works for me and
the other getopt parsing should be excised and separated by the original
writer.

** Attachment added: "new killall5.c file which correctly skips omitted 
essential processes"
   http://launchpadlibrarian.net/15772912/killall5.c

** Changed in: sysvinit (Ubuntu)
       Status: New => Confirmed

-- 
Sendsigs should always skip fuse filesystems
https://bugs.launchpad.net/bugs/151580
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to