On Wed, Oct 29, 2008 at 7:48 AM, Vladimir Dronnikov <[EMAIL PROTECTED]> wrote:
>> > + // umount -a
>> > + // ???
>> >
>> > Do we really want to hard-reboot without remounting RO
>> > or unmounting filesystems?
>> >
>
> I must expand "// ???" to be the real umounting. I got stuck here hesitating
> whether to just spawn("umount -a") or try to reimplement umount -a by
> hand...
In this spot, don't you have a feeling that it's just _impossible_
to devise a perfect reboot code *here*? Simply because
you can't know what user might want to do before reboot.
Should you try to free loop devices? If not, unfreed loop devices
might prevent clean unmounts. Should you send a message
to all logged-in consoles? What about not killing
openvpn tunnel carrying your NFS traffic *before*
you try unmounting, as otherwise unmounting will fail,
*and* many other things too because paging-in of executable
pages will stop? There are so many different scenarios
that you simply can't write code which will be good for them all.
The approach I advocate is - don't do it *here*.
Here you need to only make sure that you do not screw up
reboot by doing something silly (like exiting
and making kernel oops). Everything else should be done
by the reboot command (or most likely, it will be a shell script),
not by init (process with PID 1).
Repeat after me - "reboot should be a reboot.sh".
Allow system admin to have a convenient place
to tailor his reboot sequence to his needs.
The patch I committed does the above. If runsvdir has PID 1,
it will not exit on any signal, but will sleep for 60 seconds.
If it is a reboot indeed, we probably got this signal
because user's reboot.sh does "killall5 -TERM"
at some point in order to terminate all processes.
But not us, we are init. So just give it some time,
and do not restart services it is trying to terminate!
60 seconds should be enough for reboot.sh to do its thing.
If not (it was "kill 1" thing, not reboot.sh), we resume
monitoring of our service directory after one minute
(being rather confused - "what was that?").
--
vda
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
