Re: Could s6-scscan ignore non-servicedir folders?

From: Steve Litt <>
Date: Wed, 21 Jan 2015 13:03:11 -0500

On Wed, 21 Jan 2015 18:24:58 +0100
Olivier Brunel <> wrote:

> Hi Laurent,
> So you mentioned breaking compatibility recently, and I figure that
> might be a good time for me to mention something. I'd like to set up
> my system around s6, and have been working on this lately.
> I'll have to setup some scripts for different init stages, using
> s6-svscan as stage 2, as you've described elsewhere. But I also want
> to have a system to start (and stop) services in order. I see this
> whole idea of order/dependency is something that is being talked
> about, but currently not supported.

Can't you do something like this:

> Furthermore, I want this system of mine to include other kinds of
> services, that is one-time process/scripts that needs to be run once
> (on boot), and that's it. And to make things simpler, I want to have
> it all work together, mixing longrun services (s6 supervised) and
> oneshot services when it comes to dependency/order definition.

I do too. If you have a run-once thing that quickly returns, couldn't
you just not exec the thing in the run script, and then have the last
statement in your run script write a "down" file to the service? I'm
assuming that s6 does down files the same way as daemontools.

Then, all that remains is to have stage 1 of your boot delete all the
down files that were put there to achieve run-once.

If it really is a daemon, but you don't want it respawned, couldn't you
have the "finish" script (they have those in runit, I don't know about
s6) write the "down" file?

You know what you could do? You could make a $servicedir/oneshot
shellscript that does something like this:

touch ./down
cat "rm $scriptname/down" >> $whatever/

Then all you'd need to do is run $whatever/ in stage
1, and right after that truncate and make executable


Steve Litt *
Troubleshooting Training * Human Performance
Received on Wed Jan 21 2015 - 18:03:11 UTC

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