Sujet : Re: Faking a TTY on a pipe/socketpair
De : rweikusat (at) *nospam* talktalk.net (Rainer Weikusat)
Groupes : comp.unix.programmerDate : 09. Dec 2024, 17:24:21
Autres entêtes
Message-ID : <87plm0hlje.fsf@doppelsaurus.mobileactivedefense.com>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Muttley@dastardlyhq.com writes:
On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
>
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>
What “single task” did init do?
Boot the system to usable state.
>
What would you say systemd does that is not related to that?
>
Networking, including DNS
Graphics
Logging
systemd-boot
>
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.
There's no particular reason why init should implement process
management. That init is the one program which cannot easily be replaced on
a running system, is actually a good reason why it shouldn't.
At least on Linux, arbitrary processes can become so-called subreapers
for their descendant processes (prctl(2), PR_SET_CHILD_SUBREAPER). This
means not only the already specious reason¹ that only init can wait for
processes trying to "break out of process management" by double-forking
isn't really valid anymore.
¹ Well-behaved server programs shouldn't background themselves as whether or not a
particular instance should run in the background depends on the reason
why it was started. Ie, that's a system- and situation-specific policy
decision. Backgrounding can easily be provided by a special tool for
that.