On 12/07/2015 23:53, Colin Booth wrote:
> The requirement for the s6-rc-init live directory to not exist is
> awkward if trying to go with the defaults on a distro system
Why ? I don't think any distro will create /run/s6-rc at boot
time; they'll mount /run, but /run/s6-rc won't exist. Or is /run
persistent on some systems ?
> since /run is mounted noexec.
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.
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.
> It'd be nice if s6-rc-db contents printed a newline after the last
> service for single-item bundles:
Fixed.
> 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.
> `s6-rc -ua change' also doesn't seem to do what I'd expect. `s6-rc -da
> change' brings down all running services, `s6-rc -pda change' brings
> down all running services and then starts all stopped services.
> Following that logic I'd expect `s6-rc -ua change' to start all
> stopped services, however it instead appears to do nothing. My guess
> is that it's related to the issues with -a above and that -a is only
> ever returning the things in the "up" group.
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. :)
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 ?
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.
> Not exactle a bug but the docs are wrong: the index page points to
> s6-rc-upgrade when it should point to s6-rc-update.
Fixed.
> 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. :)
> 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.
(Grrr, looks like BSD has troubles with fdopendir. Incoming more
portability hacks, yay. Please tell your BSD friends that they would have
more followers if they paid a little more attention to POSIX.)
--
Laurent
Received on Mon Jul 13 2015 - 08:40:54 UTC