Could s6-scscan ignore non-servicedir folders?

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Wed, 21 Jan 2015 18:24:58 +0100

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.

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.

So I'll have servicedir of sorts, for oneshot services. And I'm planning
of having one folder, that I tend to call runtime repository, but that
would also be the scandir for s6-svscan.

Obviously though, those aren't servicedirs in the s6 meaning, they
shoudln't be supervised, so I'd like for s6-svscan to check if a folder
does in fact have a file run, and if not to simply skip/ignore it.

That way I can have all my (longrun & oneshot) servicedirs under one
parent, and it shouldn't really break anything, since a folder without a
run file would not be really useful to supervise anyways, as it would
just try & fail to start it every 10 seconds.

The only case I see would be a folder created, scanned, and only
afterwards the run script be copied in there. But that sounds like a
very unlikely/rare scenario. (And in case it happened, one could just
trigger a rescan to fix it.)

So, what do you think of this? Would you be willing to have s6-svscan
ignore folders not containing a run file?

Regards,
-j
Received on Wed Jan 21 2015 - 17:24:58 UTC

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