killall5 during halt, trouble with nbd-client

Johan Kragsterman johan.kragsterman at capvert.se
Thu Jan 22 10:11:29 UTC 2009


Warren Togami <wtogami at redhat.com> 
Sent by: k12linux-devel-list-bounces at redhat.com
2009-01-22 08:25
Please respond to
Development discussion of K12Linux <k12linux-devel-list at redhat.com>


To
Development discussion of K12Linux <k12linux-devel-list at redhat.com>
cc

Subject
killall5 during halt, trouble with nbd-client






https://fedorahosted.org/k12linux/wiki/NBDRootConfiguration
The fastest way to boot a diskless client is with NBD root filesystem
instead of NFS.  It works great.

/dev/nbd0 squashfs mounted at /
/dev/nbd1 dm_crypt swap as /dev/mapper/swap0

Unfortunately there is a problem during shutdown...

/etc/init.d/halt contains:
action $"Sending all processes the TERM signal..." /sbin/killall5 -15
sleep 2
action $"Sending all processes the KILL signal..."  /sbin/killall5 -9

Thereafter it stops swap and unmounts filesystems.  Only it gets stuck
and fails to reboot or poweroff here, because the underlying block
devices have disappeared due to killall5.  The two nbd-client instances
that were running /dev/nbd0 and /dev/nbd1 block devices are now gone,
causing the system to get stuck.

Would iscsi root filesystem have the same problem during shutdown?

It seems NFS root shutdown doesn't have this issue because there is no
userspace process to kill that would kill the filesystem mount.

Any ideas how we can cleanly handle shutdown in cases like NBD where a
userspace process is providing the block device, but gets killed
prematurely?

Warren Togami
wtogami at redhat.com



What´s the ubuntu approach? Did they solve it? I remember I tested it some 
1/2 year ago, and I think it was the same problem then. But they might 
have got further now?

About iScsi: I think it is different if you use iScsi with a HBA or not. 
The HBA firmware will keep the block device alive ´till everything is 
flashed. I don´t know how it works with just a nic, I wouldn´t use a nic 
for iScsi root access.

_______________________________________________
K12Linux-devel-list mailing list
K12Linux-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/k12linux-devel-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/k12linux-devel-list/attachments/20090122/dcf16a23/attachment.htm>


More information about the K12Linux-devel-list mailing list