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. :)
> 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.
> 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.
What do you have against subdirectories ?
> (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 ?
--
Laurent
Received on Wed Jan 21 2015 - 23:17:23 UTC