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
