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

Reply via email to