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
Received on Sun Jul 19 2015 - 18:13:22 UTC