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
Received on Sun Jul 19 2015 - 19:34:39 UTC