[_delirium]

Are there any examples of a process supervisor that isn't also intended to replace the traditional init system? Even systems less ambitious than SMF/launchd/systemd, like daemontools and runit, aim to replace sysvinit, because otherwise you'd have to specify twice, in different ways, how each service should start and stop (though it's possible to set up configurations where that works).

[makomk]

At the moment I'm using OpenRC which does exactly that on top of sysvinit, as are most Gentoo users. You don't have to specify everything twice because init never actually knew how to start and stop services in the first place - with a traditional sysvinit configuration that was all handled by scripts that it started, and OpenRC replaces those scripts.

[the_why_of_y]

sysvinit does have built-in service management via inittab(5); unfortunately it is so primitive that in practice it is only used to spawn getty(8).

[JdeBP]

> unfortunately it is so primitive that in practice it is only used to spawn getty(8).

The AIX System Resource Controller is spawned by a record in /etc/inittab. (AIX actually comes with utilities for maintaining /etc/inittab such as mkitab.) So too is svscanboot in daemontools 0.75 and later. Gerrit Pape is currently having problems with the Debian package for running runit, precisely because runit has for some years been run from /etc/inittab in some configurations and in Debian 8 it is suddenly no longer a file whose existence is always guaranteed because it is part of an "essential" package. There are some other packages in Debian 7 that have undocumented dependencies from the existence of an /etc/inittab file, because they too read/write it for their own purposes. I have yet to verify whether they've been fixed for Debian 8.

Don't think for one second that in the second decade of the 21st century people only ever use /etc/inittab for getty. (-:

This is one of the quieter on-going problems for Debian 8. It switches one to using systemd, because that's the Debian 8 default; but there's no upgrade path or compatibility mechanism for /etc/inittab. Every few months, another "I was (unknowingly) using /etc/inittab; I upgraded; it broke." person seems to pop up.

[Wilya]

Supervisor, god, monit, circus, etc.

And even though it can handle both init and process supervision, runit has a clear separation between the two tasks. The "runit" program handles init tasks. The "runsvdir" program handle process supervision. And each one is completely functional without the other.

[digi_owl]

I wonder how much reduced the grief would be if systemd could run on top of another init process as just a supervisor (similar to how daemontools work, and runit can work).

but then the argument is that systemd needs to be init to properly manage the cgroups etc.

[JdeBP]

> Are there any examples of a process supervisor that isn't also intended to replace the traditional init system?

Yes. You are conflating System 5 init and System 5 rc.

The IBM AIX srcmstr program is intended to be run by init, not to replace it. ("The SRC is operationally independent of the init command." - http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com... "You can also start the SRC from the command line, a profile, or a shell script, but there are several reasons for starting it during initialization" - http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com...)

Gerrit Pape's runit has "runit" (exec()ed from "runit-init") as a system manager running as process #1 doing the system management tasks that only process #1 can do, and "runsvdir" as a service manager that runs as some other process.

Daniel J. Bernstein's daemontools, Adam Sampson's freedt, and Bruce Guenter's daemontools-encore do not, strictly speaking (and pace Paul Jarc's patches), have a program for running as process #1. They all have "svscanboot", which is to be spawned by process #1 and which runs "svscan" as a service manager.

Laurent Bercot's s6 does not have a program for running as process #1. Its "s6-svscan" is a service manager, usually run as some other process. And its "s6-svscanboot" sample program is analogous to "svscanboot". It comes with examples for writing one's own program to run as process #1, but "s6 cannot provide live examples without becoming system-specific" (http://skarnet.org./software/s6/s6-svscan-1.html).

Wayne Marshall's perp has "perpd" as the service manager. This can be started by "perpboot", which (like "svscanboot") is spawned by process #1 rather than run as process #1. There's no program in the package for doing process #1 tasks.

nosh has a program for process #1, "system-manager", and a program that runs in another process to do service management, "service-manager".

All of these aim at replacing System 5 rc. Only two in fact offer in-the-box replacements for System 5 init. Do not conflate rc and init. The person that you were replying to was wrong; hence the basis for your question was wrong. Learn from "system-manager"'s manual page, "runit"'s manual page, what Paul Jarc found when he experimented with running svscan as process #1, and indeed "systemd"'s manual page to an extent. "init's job" is more than "starting a process supervisor".