On Mon, Jul 13, 2015 at 1:40 AM, Laurent Bercot <ska-skaware_at_skarnet.org> wrote:
> On 12/07/2015 23:53, Colin Booth wrote:
>>
> Ah, now *that* will be a problem. Service directories are copied
> to /run/s6-rc/servicedirs and run scripts are executed from there,
> and that will not work if /run is noexec.
> This is annoying. There are good reasons to run a daemon on a live
> copy of its service directory instead of on its stock service
> directory, which could be on a read-only filesystem.
> An ugly alternative would be to put dangling symlinks for supervise/
> and event/ in the database's service directories, but this would
> require s6-rc-compile to know about the live directory location, and
> I really don't like that.
> Another ugly alternative would be to symlink, not copy, run and
> finish scripts only, but then other scripts in the service directory,
> callable from run and finish, won't work, which defeats expectations.
>
Those options are all bad. My workaround was to mount a new tmpfs
inside of run (that wasn't noexec) but that made using s6-rc annoying
due to the no directory requirement. I don't think there's anything
inherently bad about nesting mounts in this way though I could be
mistaken.
>
> I'm inclined to simply document that /run should *not* be mounted
> noexec - it's no more dangerous to exec stuff on a tmpfs than on another
> read-write filesystem, and there's no particular reason to enforce
> noexec on /run unless you have an embedded appliance with a read-only
> firmware and no user programs at all, in which case s6-rc is probably not
> useful anyway. But I'm pretty sure distro maintainers would bitch and
> whine and dismiss s6-rc, because, you know, "security".
>
> I'm open to any ideas to solve this.
>
My suggestion is for one of: changing the s6-rc-init behavior to
accept an empty or absent directory as a valid target instead of just
absent, adding a flag to s6-rc-init to ignore the mkdir portion of its
setup, or adding a --rc-root=DIR configure option. The first option is
my own preference since it's the most flexable but I can see arguments
for the others.
>
>
>> s6-rc -da list doesn't seem to work right. At least, it doesn't work
>> like I'd expect, which is to show all services that are down.
>
>
> Hmm. Interesting.
>
> It's not how it works logically.
> "s6-rc -a list" just puts your up services in the selection, then
> prints the selection - and the -u/-d flag has no influence on it,
> because the selection is the same anyway. Contrary to "listall",
> where dependencies are closed, and s6-rc needs to know whether you're
> going up or down to perform the correct closure.
>
> However, your expectation makes sense; it needs specialcasing the
> -u|-d flag for "list", but at a human level, it's more intuitive than
> the purely logical behaviour. I changed the behaviour and documented
> it, tell me what you think.
>
The changed behavior is exactly what I'd expected initially. The
original behavior makes sense for the logical case, but it's nice
being able to actually see the state of the world from the rc systems
perspective.
>
>
> Yes. -a doesn't select everything, it only selects what's up. So
> "s6-rc -ua change" is expected to do nothing, because you're changing
> the state to the current state. :)
>
Clearly, I can't read.
>
> Contrary to the "list" above, however, I think this is intuitive,
> because -u, -d and -a always have the same meaning. Does -a need to be
> documented more clearly ?
>
Hm, either the documentation or my reading skills need work (and I'm
not really sure which). I think what threw me was that I'd been
assuming that -a was shorthand for "all services" instead of "all
active services" which was then modified by the -u/-d flags. In my
reading would have gotten the following option interactions:
-da list = show all down services
-ua list = show all up services
-da change = bring down all services
-ua change = bring up all services
-pua change / -pda change = swap all up and down services (while the
selection logic is reversed, the behavior is the same).
>
> If you think it's necessary, I can add a -A option that would mean
> SELECT ALL THE THINGS, but I'm afraid it would be misused, and it's
> easy enough for administrators to make a bundle containing everything
> if they so choose.
>
No. I'd been assuming that -a and the hypothetical -A were the same. I
still prefer my mis-read over the actual functionality of -a, but I
can get over it. You are right that people would misuse it but people
will misuse an all services bundle just as quickly.
>
>> Lastly, I know you're working on it but s6-rc-update will be much
>> appreciated. Having to tear down the entire supervision tree, delete
>> the compiled and live directories, and then re-initialize everything
>> with s6-rc-init is awkward to say the least.
>
> Oh yes, s6-rc-update is absolutely necessary for s6-rc to be more
> than just a toy. :)
>
Actually, assuming you're only making bundle and dependency changes,
it looks like swapping out db, n, and resolve,cdb from under s6-rc's
nose works. I'd be unsurprised if there were some landmines in doing
that but it worked for hot-updating my service sequence.
>
>> That's everything I've found in an hour or two of messing around. I
>> haven't done anything with oneshots or larger dependency trees yet, so
>> far it's just been a few getty processes and some wrapper bundles.
>
>
> Thanks a lot for your comments ! Much, much appreciated, and very
> useful.
>
Glad to hear it. So far s6-rc feels like what I'd expect from a
supervision-oriented rc system. There are some issues that I I haven't
mentioned but I'm pretty sure those are mostly due to unfamiliarity
with the tools more than anything else.
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 Mon Jul 13 2015 - 15:35:22 UTC