From When the operating system shuts down, how does a service manager know that it should sends SIGTERM and SIGKILL to its services?

systemd IS BOTH the init and service manager

What is the difference between "init" and "service manager"?

I guess they are the same thing?

What is some example which is "the init" but not "service manager"? Vice versa?

Thanks.

init is (usually) the first process started by the system. It has a couple of special responsibilities, including (but not limited to:

• Starting whatever other userspace processes are necessary to finish the boot up process.


• Handling the final shutdown of the system (init is what ultimately tells the kernel to power off or reboot once everything in userspace is shut down).


• Adopting orphaned processes (processes which no longer have a running parent process) and cleaning up after them.

A service manager, on the other hand, is solely responsible for ensuring a given set of services are running, and optionally that they keep running. The exact approach to this can vary from rudimentary scripts that just track dependencies among services, to complex systems that automatically manage dependencies.

The original SVR4 init implementation (which is the basis for both the classic systemv-init packages on most Linux distributions, the Busybox init applet, and the BSD and Solaris init programs) actually included rudimentary service management. It let you define programs which it would automatically start at boot, and restart if they exited. As a result of this, it's actually pretty hard to find an init implementation on a UNIX-like system that isn't also a rudimentary service manager, and this baseline level of service management is largely implied to be part of the init process's job.

On the other hand, you can easily have a service manager that isn't an init implementation. The classic BSD rc.d scripts are an example of a really simple service manager (they handle starting and stopping services, and provide rudimentary dependency management), and they formed the basis of the concept of /etc/init.d on Linux. A more complex example is monit, which adds state tracking, automatic restart capabilities, alerting, and some system monitoring support to the basic functionality.

init is the conventional name of the program that runs in process #1. It has taken many forms over the years, and the tasks that init programs have performed have significantly varied. Confusingly, it is also the name of a command that administrators use to communicate with process #1. They are best regarded as two separate things, and were certainly documented that way in AT&T Unix, even if they are in some softwares all mixed up in one program that behaves differently according to what process ID it finds that it has. Further confusingly, there can be multiple different programs run by process #1 in the lifetime of a system, at least two of which (in the case of Linux systems with an initramfs) are named init (/init in the initramfs and /sbin/init in the eventual root filesystem, conventionally chained-to by the former).

A service manager is a program that manages services, as the name says. It does not have to be run as process #1, and in fact, over the broad spectrum of operating system softwares over the years, generally has not been process #1. Service managers range from Gerrit Pape's runsv through Laurent Bercot's s6-supervise to the imaginatively named service-manager in my nosh tooset. They also encompass the Service Access Facility of AT&T Unix System 5 Release 4, the System Resource Controller of IBM AIX 3.1, and the Service Management Facility of Solaris. They spawn service programs from a uniform, consistent, known context, and provide mechanisms for those services to be controlled (brought up, terminated and restarted, and taken down) and their statuses to be queried by the rest of the system.

A system manager is a program that manages the system, dealing in system state changes. It generally is run as process #1. This is in part because the kernel of the operating system treats it specially, sending it information about system state change requests, such as power failure events or special key chords on the kernel virtual terminal's keyboard device(s) (e.g. on Linux
⇮+↑ generating SIGWINCH or ⎈+⎇+⌦ generating SIGINT to process #1). It also deals in setting up the initial system state at bootstrap, and sometimes in finalizing the system state at shutdown.

The details of system state vary from software to software. The van Smoorenburg init operated in terms of the (now passé) run-levels. BSD init's state machine is entirely internal and has states such as running /etc/rc, multi-user, and single user.

Case studies:

• 
  systemd is a process #1 program. It performs both service management and system management in one program, running as that process. However, it does not deal in finalizing the system state, instead chain loading process #1 to a different program named systemd-shutdown for that. System state changes generally take the form of the service manager starting/stopping targets which in turn cause the start/stop of services. Several services, such as emergency.service and systemd-halt.service for examples, when activated themselves run systemctl which sends commands back to process #1, for making further system state changes. Shutdown is a two-state sequence, in this design.


• The imaginatively named system-manager in my nosh tooset is a process #1 program that only does the system manager rôle. It does the initialization at bootstrap and the finalization at shutdown. It manages the system by spawning the (system-wide) service manager as another process and various invocations of the system-control program in response to events. (The SIGINT resulting from the ⎈+⎇+⌦ chord on the KVT keyboard causes it to spawn a child process to run system-control start secure-attention-key, for example.) system-control issues commands to the service manager to start and stop services and targets. Similarly, several services/targets invoke system-control to send commands back to the system manager so that upon their activation further system state changes are requested. Service processes are grandchildren of process #1.


• 
  runit is a process #1 program that also does only the system management. It spawns the service manager as other processes. This is done in what runit people call "stage 2", by invoking a shell script that in turn chain loads runsvdir which in turn spawns the several runsv programs as grandchild processes of process #1. Service processes are great-grandchildren of process #1. System management takes a "just run three shell scripts" approach, triggered by a combination of signals and flag files.


• System 5 init was a process #1 program that only did the system management. It had the aforementioned run-levels as its system states, and in theory could be a service manager as well. In reality, its service management capabilities were so feature poor that after a few years they were not even used for TUI login service management any more. It spawned (far more functional) service managers as child processes, in the forms of the aforementioned SAF and SRC.

  By 1990 the number of run-levels in use shrank to 1, yielding much the same design in actual operation as the nosh system-manager all of these decades later, with process #1 largely just spawning a service manager child process and further child processes to run commands in response to kernel events and administrator commands. Service processes are great-grandchildren of process #1, grand-children and children of the various service manager processes. (A TUI login service process is spawned by the ttymon process, itself spawned from the sac process, spawned by process #1, for example.)

  
  


• van Smoorenburg init is like System 3 init and System 5 init were in the few years before the advent of the aforementioned service managers in Unix. It is a process #1 program that performs the system manager rôle and that also manages some services (albeit in the same feature poor way, not allowing fine grained control of starting/stopping individual services, as System 5 init). Service management, if it is done at all (rather than just forking off service programs and largely forgetting about them), is done by other programs in child processes.

  In contrast to both systemd and the nosh toolset's system-manager it leaves some system management actions to programs running in child processes. Whereas both systemd and system-manager perform the final act of system poweroff/restart/halt (making the appropriate system call to the kernel) in process #1 (albeit in another program in the systemd case), in the van Smoorenburg system these are performed in child processes invoked via rc. For example: The final system call that enacts halting the system is performed via a halt shell script run as a child process of rc (itself a child of process #1) that in turn runs the halt program (as a great-grandchild of process #1) that actually makes the system call.

  
  

Further reading

• Jonathan de Boyne Pollard (2018). The Unix Service Access Facility. Frequently Given Answers.


• Jonathan de Boyne Pollard (2015). /etc/inittab is a thing of the past.. Frequently Given Answers.


• Jonathan de Boyne Pollard (2018). run-levels are things of the past.. Frequently Given Answers.


• Jonathan de Boyne Pollard (2018). getty spawned from init is a thing of the past.. Frequently Given Answers.


• Linux - IPC with init


• What exactly does init do?


• What is the difference between these commands for bringing down a Linux server?


• https://retrocomputing.stackexchange.com/a/8290/1932

It is a very good question, and not one that can be answered quickly. My answer comes in complement of JdeBP's.

When we talk about an "init system", we are really talking about 4 different things, see below. This is a confusing domain, because few people have really taken the time to separate the involved concepts - and even those who have sometimes disagree on the terminology! :-)

For instance, what Jonathan calls a service manager, I call a process supervision system, because it manages processes, not services. More accurately, it provides an abstraction ("services", although it only covers longrun services, i.e. services that are implemented via a daemon) while hiding the implementation of that abstraction (processes), so that users can address services instead of processes.

And what Jonathan calls a system manager, I call a service manager, because it's actually a tool that starts and stops services, so it arguably manages them - but it's the tool that handles the global state of the machine, so the "system manager" terminology also makes sense. Even though I'd prefer machine state manager. Anyway, we should really get to a consensus about the terms, that would tremendously help reduce confusion.

So, what is an init system? It's really 4 things:

• The first program that is run when your machine boots. Traditionally, it's named /sbin/init, and that's the terminology I use when addressing this program.


• The long-lived program that runs as pid 1 during most of the lifetime of the machine. It may or may not be the same program as /sbin/init, because /sbin/init may exec into other programs. For sysvinit, or systemd, pid 1 is /sbin/init. For an s6-based system, it isn't.


• A process supervision system. This is basically a system that restarts daemons when they die, plus tools to address the current incarnation of the daemon no matter what pid it has. It is necessary for an init system to have this for at least one process, because if it doesn't, then all processes on the system (save pid 1) could die and the machine would become unusable and require a reboot from console.


• A machine state manager (to avoid ambiguous terminology). This is the software that brings your machine state from "everything is down" to "all the services I want are up", and that can also change the set of running services while your machine is running, and trigger a shutdown.

Those are the 4 important parts of an init system. So, how do existing init systems work?

• sysvinit provides /sbin/init, pid 1, a very rudimentary supervision system (implemented via lines in /etc/inittab), and no machine state manager. Distributions using sysvinit generally use sysv-rc (the traditional bunch of shell scripts) or OpenRC as machine state manager.


• OpenRC is a machine state manager. Recent versions of it also provide a rudimentary supervision system. But it does not provide /sbin/init or pid 1: OpenRC is not an init system per se.


• systemd provides all 4 elements, in a single process. So, yes, systemd is both "the init" (which could mean /sbin/init or pid 1 or both) and "the service manager", whether "service manager" means supervision system or machine state manager.


• All the daemontools-like approaches are essentially supervision systems. runit also provides a /sbin/init and pid 1. s6 provides a pid 1, but no /sbin/init, but the s6-linux-init package provides a /sbin/init. Those approaches do not provide a machine state manager, but s6 provides hooks for such managers and two have been written: s6-rc and anopa.


• 
  nosh provides all 4 elements, in separate processes. Jonathan will be able to talk about it much better than I would. :-)


• When you look at any other init system (busybox init, BSD init, launchd, other approaches like Epoch, etc.) it is a good idea to wonder: what elements does this init provide? what is it lacking?

I have a 15-minute video explaining what I can only sum up briefly in this post, as well as a bigger deck of slides diving deep into the workings of an init system. All of it is available at the FOSDEM 2017 archive. Please feel free to explore. If you are interested in these things, we talk about them on the supervision mailing-list.

Enjoy,