> This is the right way to proceed:
> * First s6-rc -da change
> * Then s6-svscanctl -t /run/service
>
> I don't understand the issue you're having: why would your rw filesystem
> be set read-only before the services come down ?
> - Your non-root filesystems should be unmounted via the corresponding
> "down" scripts of the oneshot services you're using to mount them, so
> they will be unmounted in order.
> - Your root filesystem will be remounted read-only in stage 3, i.e.
> when everything is down.
>
I was a bit unclear last night. I'm not concerned about things that
are under the control of s6-rc, those of course should be shut down in
the correct order as per s6-rc's design. I'm concerned about stray
backgrounded processes, supervised things that s6-rc doesn't know
about, etc.
My current issue is that I'm initially remounting my root filesystem
as r/w as one of the first steps for s6-rc, which means that if I'm
doing everything correctly, s6-rc attempts to remount root as
read-only as part of its shutdown. That should be safe, since if any
program has a file open for writing when you attempt to remount it,
the operation will fail and get re-attempted in stage 3. I'd like to
account for a situation where where are no open write handles, some
program has escaped the control of s6-rc, and that program will
attempt to write state to disk when signalled. I'm currently getting
around that by having s6-rc not do read-only remounting and instead
solely doing it in stage 3 after the last sync call but I was
wondering if there was a better way.
>
> If your dependencies are correct, there should be no problem. What
> sequence of events is happening to you ?
>
Mentioned above, but explicitly the sequence that I'm concerned about is:
s6-rc shuts down all s6-supervised services
s6-rc successfully remounts all devices read-only
s6-svscan receives terminate signal and execs into finish, which
execs into stage3 teardown script
s6-nuke -t catches an orphaned process which attempts to open a file
for writing out persist state
I probably shouldn't be worrying about that particular scenario since
it's pretty rare but I've been thinking about it.
>
> Yes, an empty ./up script will work. (Oneshot scripts are interpreted
> at compile time by the execlineb parser, which treats an empty script
> as "exit 0".)
>
Cool, thanks. That's what I thought but I wasn't sure to what degree
execlineb cared about script validity and I don't have a terribly
great test methodology for oneshots figured out yet.
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Sun Sep 13 2015 - 18:25:09 UTC