On Friday 31 October 2008 04:29:54 Denys Vlasenko wrote: > On Friday 31 October 2008 03:57, Rob Landley wrote: > > 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. > > Ok, an example where I don't even mount a loopdevice, > but still can't remount my root RO as long > as loopdevice eixsts:
Yup, losetup associating the file with the loop device node pins the device, just like any other process having an open file in the filesystem would. > > 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. > > What "umount -r -a" should do if remounting RO fails? "losetup -d" > every possible loopdevice and retry? This is really a kernel issue. (I do note the existence of umount -f, but that's probably not something you want to do on /.) Ask the kernel guys. Being unable to remount / read only seems like a bug to me, no matter what the reason. > > 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. > > In the case we are using per-process mounts, yes, > killing processes helps with umount. Just having _files_ open prevents umounting a mount without -f: sudo /bin/bash mkdir walrus mount -t ramfs walrus walrus touch walrus/walrus sleep 999 < walrus/walrus umount walrus A process has a file open in it. The filesystem is pinned until the process closes that file, unless you want to force the unmount (so the file starts getting a -ESOMETHINGOROTHER). (Having a process with its current working directory in that filesystem also pins it.) > > 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. > > We do it not from process 1 but from it's children anyway. > Not much difference. So instead of signaling PID 1 to do the work, you signal PID 1 to stop respawning processes and have some other script do it. Hoping that script isn't in a chroot, hoping that script isn't running in a process context with per process mounts... > > 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? > > Yes, I have to kill all processes. killall5 does that nicely. killall5 can't kill PID 1, and if your non-init process doesn't kill itself then you didn't kill all processes. PID 1 is the only process that can ever be the only process on the system. By definition. Therefore, unless PID 1 is quiescing the system you have two sets of per-process resources to free. > -- > vda Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
