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

From: Charles Duffy <charles_at_dyfis.net>
Date: Tue, 21 Jun 2016 15:18:38 +0000

Couldn't one play with bind mounts to keep the absolute paths consistent on
both sides of the pivot operation?

On Tue, Jun 21, 2016 at 10:02 AM Laurent Bercot <ska-supervision_at_skarnet.org>
wrote:

> On 21/06/2016 16:24, Martin "eto" Misuth wrote:
> > 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):
>
> No, it's not the same thing. When you pivot_root, everything is kept
> open,
> the inodes do not change, everything keeps working - except that the
> absolute paths to the files are not the same anymore. If you were referring
> to a service as /service/foo beforehand, it has to be referred to as
> /old_root_location/service/foo after a pivot_root.
>
> If you used absolute paths to link servicedirs into your scandir, and you
> pivot_root, then s6-svscan will rightfully freak out on its next scan. But
> s6-supervise should keep working - the control interface hasn't
> disappeared,
> it is just named differently.
>
>
> > 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?
>
> No. Well, there are "extended attributes" that allow you to do that kind
> of
> thing, but I'm not sure to what extent those are portable. But they
> wouldn't
> protect you against pivot_root anyway, because no files are deleted or
> changed when you pivot_root, it's just a rotation in the directory tree.
> (Also, trying to protect admins against themselves is doomed to fail, and
> a sure recipe for bad design.)
>
> The only sensible "protection" against pivot_root is: do your pivot_root
> very early when basically nothing is running, and start your supervision
> tree later on.
>
> --
> Laurent
>
>
Received on Tue Jun 21 2016 - 15:18:38 UTC