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: