On Thursday 30 October 2008 06:07, Rob Landley wrote:
> On Wednesday 29 October 2008 07:04:50 Denys Vlasenko wrote:
> > 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?
>
> Nope, kernel does that.
It does not. I have my root device mounted RO.
My kernel is 2.6.26. Let's experiment.
# mount -o remount,rw /
# dd if=/dev/zero bs=1M count=10 >/z
10+0 records in
10+0 records out
# mke2fs /z
mke2fs 1.34 (25-Jul-2003)
z is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
...
# mkdir /tmp/z
# mount -o loop /z /tmp/z
# mount -o remount,ro /
mount: mounting /dev/root on / failed: Device or resource busy
Oops... Maybe if we will remount loop device RO?
# mount -o remount,ro /dev/loop0
# mount -o remount,ro /
mount: mounting /dev/root on / failed: Device or resource busy
Still nothing.
Looks like robust reboot procedure should try to free all
loop devices in order to avoid this. Should we patch init here?
/* No inittab file -- set up some default behavior */
if (parser == NULL) {
/* Reboot on Ctrl-Alt-Del */
new_init_action(CTRLALTDEL, "reboot", "");
/* Umount all filesystems on halt/reboot */
new_init_action(SHUTDOWN, "umount -a -r", "");
/* Swapoff on halt/reboot */
if (ENABLE_SWAPONOFF)
new_init_action(SHUTDOWN, "swapoff -a", "");
> > If not, unfreed loop devices
> > might prevent clean unmounts.
>
> If so, that's a kernel bug.
If it's a bug, it is not yet fixed.
> People have been somehow getting by with init for 30 years. This would seem
> to imply it can be done.
I am not removing stuff from init. I am trying
to avoid adding the same awkward method of rebooting
to runsvdir.
> > Allow system admin to have a convenient place
> > to tailor his reboot sequence to his needs.
>
> Shutdown signals init, init has a script it can call to quiesce the system.
Only one detour? Let's start ten processes and pass a few different
signals between them. That will open way to more interesting bugs.
> If you don't notify init not to respawn things, then your script will kill
> things and init will re-launch them and the system will never quiesce.
E-xac-tly. That's why I just taught runsvdir to become quescent on reboot.
That's the minimum I need to do, and I intend to do only the minimum.
--
vda
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
