On Friday 12 September 2008 08:25, Vladimir Dronnikov wrote: > My boot process is: /init mounts critical FSs, mdev's -s, mounts /usr and > does "exec /usr/sbin/init". The latter in turn does some housekeeping and > does "exec setsid runsvdir -P /etc/init". So I do run runsvdir as #1. Thus > to even "sync ; umount -a" at halt/poweroff/reboot I must have an > "arriere-guarde". I tend to try to locally patch runsvdir to catch USR1, > USR2 to handle poweroff/reboot requests. With our unified signal catcher it > is a trivial task now. The whole runsvdir then would be similar to toybox > oneit which I discovered recently and consider as a "must have". > > > And if so, we can not just exec runsvdir at the end of > > > init. M.B. patch runsvdir so it could take a command to execute upon > > exit? > > > > Or execute this command before killall5 -TERM. This way no patching > > is required. > > Pity, but "sync ; umount -a" can't be issued successfully before killall5 > -TERM, I think.
Yes, umount will most likely fail. "sync &" makes sense to speed up writeout, in particular, to make machine do something useful while "killall5 -TERM; sleep N" waits for processes to exit. "&" ensures that you won't stall at sync. But it's not a problem. umount has to be issued AFTER killall5, not before. In reality, you would want something like: sync & killall5 -TERM sleep $DELAY killall5 -KILL sleep $DELAY # in case umount fails, I want to know that I at least synced sync sleep 1 # disk write caches are evil umount -a hardshutdown -r -- vda _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
