Re: Preliminary version of s6-rc available

From: Laurent Bercot <>
Date: Sun, 19 Jul 2015 21:34:39 +0200

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...

Received on Sun Jul 19 2015 - 19:34:39 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC