3

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 ?

7

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:
  • 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:
  • If it is running Joachim Nilsson's finit:
  • 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.
    • 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

  • Actually I'm writing a daemon to work with a Raspberry Pi specific UPS add-on and I am using that initctl to tell init (I'm not doing anything with that there new-fangled systemd thingy - at least not until it gets to be a lot more stable in extreme cases) when the Main power has dropped and come back - and when to shut down because the battery is running critically low. The intricacies are not that complex but I am using it because that is exactly what that API is intended for. – SlySven Feb 29 '16 at 7:32
  • Thank you for the mention :) Finit also supports UNIX domain socket IPC. – troglobit Mar 23 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.