some patches

[Denys Vlasenko]

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