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
