> #!/usr/local/bin/execlineb -P
If you're a distributor: don't do that. Distributions should not install
anything in /usr/local.
Also, if you're providing s6 as the base init system, you should have the
execline binaries in the root filesystem, which means /bin. Because the user
may choose to have /usr on a different filesystem.
> foreground { s6-hiercopy /etc/s6/user-serv /run/user }
Do you need to perform that step every time your service restarts?
It's idempotent, so you should put that in a separate oneshot, instead of
in a run script.
> if { if { s6-mkdir -p -m 0755 /run/user-run/ } forbacktickx -p -0 i {
> s6-ls -0 /run/user } import -u i foreground { s6-ln -s --
> /run/user/${i} /run/user-run/ } }
Same thing: that's idempotent, so put that in a separate oneshot.
Besides, all that accomplishes is add another level of indirection.
Why do you need /run/user-run with symlinks when you could just use
/run/user ? /run/user is already a working copy of your user data in
/etc/s6/user-serv, why do you need an additional directory where you're not
adding anything meaningful ?
> s6-envdir -I /run/user-run/service/.s6-svscan
I don't think that does what you think it does. Nothing in .s6-svscan is
meant to be read and put into environment variables.
> then i launch a s6-rc-init by a oneshot just after like this :
Hmmm. This means that your user s6-svscan should notify readiness.
It's difficult to have a s6-svscan service notify readiness, because how do
you define readiness?
- If it's just that the s6-svscan process has entered its main loop and can
now receive signals and commands and process the scandir: that's easy to do,
but doesn't mean much.
- If it's that the whole supervision tree at the time of launch, i.e. all the
early services, are ready: that's a bit harder to implement, it implies
running s6-svwait -a on all early services. Which is doable, but requires
the run script to be a bit more complex than the one you wrote.
> #!/usr/local/bin/execlineb -S0
> s6-svscanctl -q -- /run/user-run/service
That's not going to work. Your s6-svscan service is a longrun, so your
supposed "down" file will be ignored; it's not doing anything, you should
delete it.
What is happening is that your user s6-svscan is sent a SIGTERM when s6-rc
decides it's time to bring it down. Which is the right thing to do.
Note that you launched s6-svscan with -s, so what SIGTERM does depends on
the contents of /run/user-run/service/.s6-svscan/SIGTERM. That's probably
not a good idea for a s6-svscan instance that is not the main one. My
suggestion would be to just remove the -s option in your run script.
> The rc database bring down correctly the service declared on it but
> the scandir do not want to stop.
I suspect you don't have a script for SIGTERM, so s6-svscan is happily
ignoring it. Just remove the -s option to s6-svscan and everything will work
fine.
> However, i have a another trouble, when i try to launch some classic
> service with the second scandir(or the first, it's equal) i have this
> error on the log : _at_40000000575cf0bb05fd2e24 s6-supervise
> syslogd-linux/log: warning: unable to spawn ./run - waiting 10
> seconds _at_40000000575cf0c504c9de44 s6-supervise syslogd-linux:
> warning: unable to spawn ./run - waiting 10 seconds
> _at_40000000575cf0c504ca5f2c s6-supervise (child): fatal: unable to exec
> run: No such file or directory _at_40000000575cf0c50660c63c s6-supervise
> (child): fatal: unable to exec run: No such file or directory
You have an invalid "syslogd-linux" service directory, with no run script.
Same thing with syslogd-linux/log. Check what is happening to your run
scripts.
--
Laurent
Received on Mon Jun 13 2016 - 13:33:05 UTC