Linux - IPC with init

Question

The init process exists as an ancestor of all of processes on a linux system. Does this process have any kind of IPC entry point ? Do other processes ever do IPC with init for any reason ?

Answer 1

Don't conflate processes and programs. There's one process #1, but it can be running one of a number of different programs.

• If it is running the systemd program from the systemd package:
  • There is an internal systemd API accessible via D-Bus, that is not guaranteed stable and not intended to be used by things outwith the systemd package.
  • It responds to a large set of signals, ranging from SIGWINCH and SIGPWR to SIGRTMIN + 4.
• If it is running the system-manager program from the nosh package:
  • It responds to a fairly large subset of the signals recognized by systemd, with the same meanings where applicable.
• If it is running the init program from upstart:
  • There is an internal upstart API, accessible via D-Bus.
  • It reads command messages from the initctl FIFO.
  • It responds to small set of signals.
• If it is running Joachim Nilsson's finit:
  • It reads command messages from the initctl FIFO.
  • It responds to a small set of signals.
• If it is running the System 5 init then:
  • It reads command messages from the initctl FIFO.
  • It responds to a very small set of signals.

Some notes:

• The signal API is mandated by the things that send the signals to process #1. These include the operating system kernel, which sends things like SIGWINCH, SIGINT, and SIGPWR, and various widespread system utility programs.
  • Both systemd and the nosh system-manager extend this with signals that command system state changes (such as shutting down and powering off the system).
  • Not all programs document supporting the full set of system-mandated signals. upstart makes no mention of responding to SIGPWR, for example.
  • finit recognizes a different set of non-system-mandated extended signals, including SIGSTOP and SIGCONT.
• Although the systemd package doesn't implement the initctl FIFO API in the program that runs as process #1, it does provide a compatibility shim in another process, running another program, that translates that mechanism onto native systemd mechanisms. (The nosh toolset has its own initctl-read compatibility shim that similarly translated into the native mechanisms of the nosh toolset's system management.)
  • initctl really isn't native to anything but System V init, as the others (if they do so at all) only implement the notion of run levels as a limited backwards-compatibility mechanism.
  • As the upstart man page for its init program says, the initctl mechanism isn't well documented. Even the System V init people go around telling people that only things in the System V init package should use it. It doesn't help, moreover, that the Debian System V maintainers relocated it from /dev to /run.

So yes, programs do IPC with process #1. Their reasons for doing so vary.

• The systemd program is a combination system manager, service manager, and control groups manager and so there are a lot of purposes for which programs employ IPC to process #1. The same for upstart's init.
• For nosh's system-manager, conversely, service management is done by another program (service-manager) in another process with its own (daemontools-compatible) APIs. So the only reason to do IPC with process #1 is for system state management, such as (say) rebooting the machine.

For many (not all) purposes, one is better off sticking to other APIs, using conventional system utilities to do things like shutdown and reboot the system, rather than sending the signals understood by the system-manager and systemd programs when they are running as process #1.

Further reading

• https://superuser.com/questions/886825/