[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: design of process #1 programs

The Wanderer:
That isn't all you gain by it;  you also gain the benefit of being
> able to use these features no matter which init system you're
> running. Which in turn helps avoid lock-in, and enable easier testing
> of (or migration to) alternatives, and prevent user surprise, and so
> forth.

Gunnar Wolf:
Yes. But it would end up  finally boiling up to having your favorite
> init spawning nothing but this newfangled ultra-process-supervisor,
> which would then start monitoring everything. That is, you'd have
> whateverinit spawn a PID 2 process, which would... Perform precisely
> systemd's tasks.

Not in fact correct. Apart from the fact that things that already existed 15 years ago (namely the process supervisors that are being discussed) are not really "newfangled" or in any way hypothetical, there are things that process #1 must do throughout the life of the system, and they do not move into a child process even if daemon/service supervision is not done in process #1.

It's often said that process #1 is the reaper of parentless terminated processes. In fact, thanks to things that really are "newfangled", that's not really a major specific process #1 task any more. Ironically, it's one of the things that can move out of process #1, contrary to received wisdom. systemd and upstart make use of the Linux kernel's "new" (just under 3 years old) ability to set "subreapers". One only sees the effects of this with "user" service managers, because the "system" ones are still process #1. The effects are that a process other than process #1 can now have the task of reaping parentless terminated processes in its part of the process subtree.

What does remain in process #1, in contrast, is system management and basic initialization of "API" devices, directories, and symbolic links. The "API" stuff is reasonably well known. Even BSD init mounts things in process #1. The system management should be, too. There's a whole load of signals that other programs expect to be able to send off to process #1 to initiate various system state changes. The kernel sends several signals to process #1, too, including SIGINT and SINWINCH. None of this stuff can move out of process #1.

In a further irony, systemd has already moved one thing out of process #1 that is done in process #1 by System 5 init: the initctl socket. This is managed completely outwith process #1 by a compatibility shim in systemd. Of course, systemd replaces it with a internal, not guaranteed, D-Bus transported "systemd process" API; which is part of the hoo-hah around systemd-shim. But asking whether that would be done outwith process #1 is making the mistake of thinking that it's the right API to be implementing in such a system in the first place; and the API that is the right one to implement isn't provided by process #1 in the systemd package anyway.

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/debian-systemd-packaging-hoo-hah.html#systemd-shim

Reply to: