On Tue, 21 Jun 2016 14:45:59 +0200 Laurent Bercot <[email protected]> wrote: > ... > With udevd, the workaround is to kill it after you have performed the > coldplug, and only restart it as part of your normal boot sequence once > you have pivot_rooted. It can be supervised at this point. >
Thank you! Especially for mdev coldplug process description! I asked, because it seems FreeBSD will be getting pivot_root like capabilities soon. This makes it more similar to Linux in a way. And opens some weekends for tinkering. It also introduces remote posibility of situation like described actually happening there too. So I got curious what is "proper" solution to such broken "state". And it seems answer is: don't do that! Reinterpreting based on my personal experience, situation would be basically similar to - "deleting" servicedirs from "underneath" running s6-svscan one (I did that one to myself due to script error, don't ask): - When I did that - once tree was "wiped"/"cleaned" out, all s6-svscan/s6-supervise special files got unlinked() and disappeared from directory tree view. Although s6-svscan/s6-supervise were holding onto those files, I was unable to control them with s6-svscanctl/s6-svc, as there were no "control points" to "connect to" in the filesystem anymore. Process tree did not dismantle though as unlinked() files are not deleted right away. Because both runit and s6 are so robust, in this case s6 just held onto unlinked fds for days and it took me some time to figure this one out. This makes me think, that situations like remounting servicedirs root/pivot_root/unlink and such, although PEBKAC, leave some less experienced sysadmin unable to control services, at least without without signals (I can attest signals always work perfectly, even in such "broken" cases). Would it be possible to somehow "posixly" lock control files in such way, that remount/pivot_root/unlink would fail and one could not delete them without force flag, indicating indeed sysadmin error? eto
