Re: How to supervise an early process [root pivot]

From: Martin \ <et.code_at_ethome.sk>
Date: Tue, 21 Jun 2016 16:24:21 +0200

On Tue, 21 Jun 2016 14:45:59 +0200
Laurent Bercot <ska-supervision_at_skarnet.org> 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
Received on Tue Jun 21 2016 - 14:24:21 UTC