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
