Implement service supervision?

[jirutka]

The main argument of systemd fanboys against OpenRC is that it doesn’t support supervision, i.e. crashed services are not automatically restarted. I agree that it’s indeed a nice feature, that comes handy in some situations, although it cannot (and should not) replace a monitoring system.

I’m convinced that it can’t be hard to implement a simple supervising in OpenRC. What do you think about it?

[williamh]

See https://bugs.gentoo.org/show_bug.cgi?id=501364. This is being worked on. The only question remaining is when to start the monitor (such as runsvdir in the example).

[tokiclover]

I was quite busy in late February scripting an agnostic supervision backend framework which is quite feature complete with CGROUP support and simple service (need) dependencies. No complicated dependecies tree scheduled because of the supervision service scan model.

What to say... I guess the approach described on the bug would ultimately fails because... First, automatic service generation would never workd because start-stop-daemon (ssd) forks long lived process (daemon) by design while particular supervision backend runs a supervised process in the foreground. There's absolutely no way to make a simple replacement of ssd by introducing a new backend without adding at least an extra option to hold the forground argument for every single init script to function properly.

Who's going to do that extra compatibility work? I guess this is manageable to some extend.

Second, service scan model makes it hard to start new services in a racy free condition but to... start new service as down state and then start them. This could be manageable as well if a particular backend behave properly--runit/s6 does this.

So the blocker is the first point because the second could resolved with that trick or possibly more or less dirty hacks. However, the dynamic {,log/}{run,finish} is not that good an idea... it will be certainly better to have a proper '/service/' directory and work with making writing a supervision backend to replace ssd not that simple to do because of logging choice and so forth. Well, I tried this first and completly abandoned the idea.

So I am nicely leaving the hot potato to others. Note, 1 has LSB compatible commands {start,stop,reload,status} plus a particularly command to add services and can be used as a starting point for more adventurous ones.

Good luck!

PS: Maybe closing this issue would be a good idea!

PS2:

Almost forget to mention that the framework has [Open]RC support to use functions.sh and service config files. This is not that usefull because there aren't that many environment variables to share besides the command and command_args... but the latter one is problematic because of the first point (above.)

Second, Init-Stage-{1,2,3} for Runit/S6 do use OpenRC to not have to write system boot/halt from scratch! I don't feel like wasting my time here when there's a good portable alternative to take care of it.

[williamh]

I'm going to close this issue since we now have multiple supervisors supported internally in OpenRC. See runit-guide.md, s6-guide.md and supervise-daemon-guide.md in the distribution. The idea of these is to hook into runit or s6 or use supervise-daemon (OpenRC's internal supervisor) to supervise long-running services and leave the rest to OpenRC.