> > I do not run runsvdir as process with PID 1. Thus when it exits, > kernel does not panic. >
My! Of course! Why only did I suppose you do?.. > > There should be something behind runsvdir to flush the system gracefully > -- > > so called stage 3. > > Why? Are you saying you have programs which do not exit correctly on TERM? > Those programs are broken. > 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. Thanks! -- Vladimir
_______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
