Re: Preliminary version of s6-rc available
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
Re: Preliminary version of s6-rc available
On 19/07/2015 20:13, Guillermo wrote: 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. Looks like your kernel can't do PATH searches. The #!execline shebang worked on Linux 3.10.62 and 3.19.1. But yeah, it's not standard, so I'll find a way to put absolute paths there, no big deal. /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 :( I committed a few quick changes lately, I probably messed up some string copying/termination. I'll investigate and fix this. * 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. It was deliberate because I didn't want to read the same subdirectory twice if there's a symlink to a subdirectory in the same source directory. But you're right, this is not a good reason, I will remove the check. Symlinks to a subdirectory in the same place will cause a duplicate service definition error, though. * 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's just so that if the compiler encounters the logger before the producer, it knows right away that it is involved in a logged service and doesn't have to do a special pass later on to adjust service directory names. It also doubles up as a small database consistency check, and clarity for the reader of the source. * 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. Right. You can have empty down files already for this purpose; I guess I could make them entirely optional. 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? Yes. And indeed, allowing s6-rc to be run by normal users implies changing the configuration on s6rc-oneshot-runner. I'll work on it. 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. That's good news ! Thanks a lot for the feedback ! I have a nice week of work ahead of me... -- Laurent
Re: Preliminary version of s6-rc available
On Fri, Jul 17, 2015 at 10:13 AM, Claes Wallin (韋嘉誠) skar...@clacke.user.lysator.liu.se wrote: On 17-Jul-2015 12:49 am, Colin Booth cathe...@gmail.com wrote: Depending on your cron, users might be able to simply put an @reboot s6-svscan in their user crontab. I don't see many drawbacks with that. There's nothing managing the per-user s6-svscan if it dies during normal system runtime, which defeats the entire purpose of using a supervision framework in the first place. With process suprevision, at some point your supervision tree must have PID 1 bringing the tree back up (be it an inittab entry, s6-svscan running as init, runit managing runsvdir and so on) otherwise you're only playing tricks with daemonization. Using @reboot crontab entries is a clever way around the reboot case, but like I said above, it doesn't protect the supervision root process outside of that event. I actually think that systemd based systems can have a correctly supervised non-privileged supervision tree through the use of loginctl enable-linger and daemon-ish unit files. So you could bring up your supervision tree that way, or just forego the process supervisor and write directly against systemd. I however don't have any systemd hosts laying around to test that on, and even if I did s6-rc and systemd both cover the same operational space. 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
