On Thursday 30 October 2008 21:24:53 Denys Vlasenko wrote:
> 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.
Ok, when you said "free loop devices", I thought you meant "losetup -d".
You're talking about unmounting loop devices, which is a standard unmounting
problem.
> 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", "");
There's a umount -a in there already, which was there in busybox 1.2. If the
busybox umount -a isn't unmounting everything properly, that's a separate
bug.
Note that mounts are process context these days, so if you kill all proccesses
except PID 1, it should naturally reference count those per-process mounts
down to zero and free them, which just leaves the PID 1 mounts that umount -a
should be able to get.
Note that if you try to do this from a process _other_ than PID 1, or without
having killed all the other processes on the system, then you're not
guaranteed to have umounted every active filesystem.
> > 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.
Ah, no problem. I don't care about runsvdir, so I'll drop this thread.
> > > 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.
See the bit about about some resources being per-processes, so you have to
kill all the processes other than PID 1 in order to make sure the reference
counts of those resources drop to zero and the system can be quiesced? (Also
to make sure the other processes aren't opening new instances of things...)
PID 1 is special. PID 1 has been special for years. If you ever need to make
sure you're the only process running on the system, you must be PID 1 or
you're doomed to failure.
> > 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.
If you don't understand how the current linux filesystem works, sure. We can
just say "busybox doesn't support per-process mount points". Or chroot, for
that matter.
Rob
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
