2015-07-12 2:59 GMT-03:00 Laurent Bercot: > > s6-rc is available to play with. > [...] I decided to publish what's already there, so you can test it and > give feedback while I'm working on the rest. You can compile service > definition directories, look into the compiled database, and run the > service manager. It works on my machines, all that's missing is the > live update capability.
Hi, Well, I haven't been very lucky with oneshots. First, the "#!execline" shebang with no absolute path doesn't work on my system, even if the execlineb program can be found via the PATH environment variable. Neither does "#!bash", "#!python", or any similar construct. If I run a script from the shell with such a shebang line I get a "bad interpreter: No such file or directory" message. And s6-supervise fails too: s6-supervise (child): fatal: unable to exec run: No such file or directory s6-supervise <servicedir name>: warning: unable to spawn ./run - waiting 10 seconds And because s6rc-oneshot-runner has a run script with an "#!execline" shebang, it cannot start, and therefore oneshots don't work :) However, I was able to work around this in two ways: either by just modifying s6rc-oneshot-runner's run script in the servicedirs/ subdirectory of the live state directory, or by using Linux binfmt_misc magic[1]. So now I'm really curious about how the "#!execline" shebang worked on your test systems. But once I could get s6rc-oneshot-runner to start, I ran into another problem. "s6-rc change" then failed to run my test oneshot with this message: s6-ipcclient: fatal: unable to connect to /path-to/live/servicedirs/s6rc-oneshot-runne********: No such file or directory s6-rc: warning: unable to start service <oneshot name>: command exited 111 "/path-to/live/" represents here what was the full path of the live state directory, and the "********" was really a string of random characters. I suppose this was meant to be the path to s6rc-oneshot-runner's local socket, but somehow ended up being gibberish instead. So oneshots still don't work for me :( Longruns without a logger work for me as expected, and I haven't tried loggers, bundles and dependencies yet. Now some other general comments: * It looks like s6-rc-compile ignores symbolic links to service definition directories in the source directories specified in the command line; they seem to have to be real subdirectories. I don't know if this is deliberate or not, but I'd like symlinks to be allowed too, just like s6-svscan allows symbolic links to service directories in its scan directory. * I'm curious about why is it required to also have a "producer" file pointing back from the logger, instead of just a "logger" file in the producer's service definition directory. Is it related to the "parsing sucks" issue? * It doesn't really bother me that much, but it might be worth making "down" files optional for oneshots, with an absent file being the same as one contanining "exit", just like "finish" files are optional for longruns. * I second this: 2015-07-14 13:23 GMT-03:00 Colin Booth: > > s6-rc-init: remove the uid 0 restriction to allow non-privileged > accounts to set up supervision trees. I test new versions of s6 on an entirely non-root supervision tree, with services that can be run by that user, separate of the "system-wide" (privileged) supervision tree, if any. And it is also the way I'm testing s6-rc now. But, independently of any potential use-cases, I really see it this way: s6-svscan and s6-supervise are already installed with mode 0755 and can therefore happily run as any user besides root. So it is possible to build a non-root supervision tree, and if some services refuse to run because of "permission denied" errors, they will be gracefully dealt with just like with any other failure mode; the user will know via the supervision tree logs, and no harm is done. So if a non-root supervision tree is allowed, why not a service manager on top of it, too? 2015-07-16 19:16 GMT-03:00 Laurent Bercot: > > I understand. I guess I can make s6-rc-init and s6-rc 0755 while > keeping them in /sbin, where Joe User isn't supposed to find them. It would be nice if s6rc-oneshot-runner's data/rules directory (for s6-ipcserver-access on the local socket) could also be changed, so it doesn't allow only root. For example, allow the user s6-rc-init ran as instead (or in addition to root), or allow the specification of an allowed user, or a complete rulesdir / rulesfile, with an -u, -i or -x option to s6-rc-compile or sc-rc-init. The user checked against the data/rules rulesdir would be the one s6-rc was run as, right? So it defines which user is allowed to run oneshots? And finally, for the record, it appears that OpenRC doesn't mount /run as noexec, so at least Gentoo in the non-systemd configuration, and probably other [GNU/]Linux distributions with OpenRC as part of their "init systems", won't have any problems with service directories under /run. Cheers! G. [1] http://www.kernel.org/doc/Documentation/binfmt_misc.txt
