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

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Fri, 23 Jan 2015 23:55:21 +0100

On 01/22/15 00:17, Laurent Bercot wrote:
> On 21/01/2015 21:47, Olivier Brunel wrote:
>> The thing is, that you've referred to services & oneshots, whereas I
>> would refer to longrun services & oneshot services resp., i.e. I see
>> those as two types of services.
>
> They are both services from a "system management", higher-level, point
> of view. From s6-svscan's point of view, longruns are services, oneshots
> are something it's entirely irrelevant for.
>
>
>> In fact, a reason I want/need one folder with everything (servicedirs
>> for both oneshot & longrun) is to avoid issues of two services with the
>> same name or such complications when resolving dependencies/ordering.
>
> Refer to services as oneshot/foo or longrun/foo, from your system
> manager's main directory. Now users can name their oneshots and their
> longruns the same thing, and your dependency manager doesn't care. :)

I can't do that, because I need to refer to services by their names, and
said name must be (able to be) a filename. Particularly useful for
setting things up in subfolders needs/wants/after/before. Otherwise it
would complicate things too much, for users possibly, in my code without
a doubt, so no.


>> To maybe explain/detail a bit more how what I'm planning would work: my
>> "service manager" is asked to start some services, it pulls dependencies
>> and ordering from subfolders (of servicedirs) needs/wants/after/before.
>> It then starts everything in order, waiting on some services to be
>> started before others can be. Starting a oneshot service would mean
>> running the start script, and waiting for it; Starting a longrun service
>> would mean sending the command to its supervise process, and waiting for
>> the event on its fifodir.
>>
>> So while the service manager does start services, when it comes to
>> longrun ones it always delegate to s6, as it should.
>
> That sounds perfectly reasonable. Make sure to also have a stop script
> in your oneshot directories, for when you deactivate the service.
>
>
>> (To be more precise, all longrun servicedirs will include a down file
>> when created (into /run), to make sure they're started as/when needed.
>> So starting a longrun service actually also includes removing the down
>> file once the event has been received (or when sending the start
>> command, I'm not sure yet which is best) to reflect the change of state.)
>
> Yeah, that's ugly, but that's because down files are inherently ugly.
> I'd say a better solution for the initial boot (which is the only time
> where you'd need down files) would be to start with an empty, or almost
> empty, scandir, and have your dependency manager auto-populate it if the
> longrun service it wants to start isn't being supervised yet.

That could be a solution, but I don't really like it. Or, it doesn't
"play nice" with what I wanna do, so I'll stick with down files I think.


>> I understand what you're saying regarding the scandir though. Now I'm
>> thinking I would have a folder with all servicedirs, oneshots &
>> longruns, and use a folder .scandir that would only contain symlinks for
>> all the longrun servicedirs.
>> That way, the scandir only has the servicedirs that needs to be
>> supervised, and the service manager still has a single place for all
>> services.
>
> That can work, but your ls output will still be confusing, and there
> *will* come a day when you'll accidentally link a oneshot directory into
> the scandir. And that will be fun.

ls output is mixing oneshots & longrun in the main folder, but in the
scandir there's only the longrun. Hopefully it won't be that confusing...
As for linking a oneshot in there, I plan on having this done
automatically, so there shouldn't be such an issue. (But if it happens,
I'll just have a supervise failing every 10s to start a non-existing
./run; nothing dramatic.)

> What do you have against subdirectories ?

Nothing at all. It's just that if I don't have one folder with all
(oneshots & longruns) services, it complicates things in my code, and I
don't want that.


>> (I might also say, that I'm planning of having this folder of
>> servicedirs be created on boot into /run, for all enabled services. So
>> it is all runtime information.)
>
> Well, you only need the oneshot information during state changes, i.e.
> mostly boot and shutdown, and on admin intervention in any case. There's
> no live, automatic state to maintain, so why have oneshot directories eat
> precious tmpfs space when they could just sleep on your rootfs ?

Well, I do in fact have state for oneshots as well, e.g. is it started,
failed to start, stopped, etc
Received on Fri Jan 23 2015 - 22:55:21 UTC