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

Re: piece of mind

On 10/21/2014 at 11:39 AM, Matthias Klumpp wrote:

> 2014-10-21 17:24 GMT+02:00 Robert Lemmen <robertle@semistable.com>:
>> hi matthias,
>> On Tue, Oct 21, 2014 at 04:35:20PM +0200, Matthias Urlichs wrote:

>>> first place. Having ten processes responsible for bits&pieces of
>>> what systemd-as-PID1 does instead of one isn't a benefit -- not
>>> if all you gain by that is nine additional processes.
>>> "It's a big monolithic thing, and big monolithic things are bad
>>> and evil and non-Unix-y, so there!!1!" is not a valid argument.
>> but that's the thing, to some (e.g. me) ten separate processes that
>> each do a fairly small thing with understandable interfaces between
>> them is an *enormous* benefit over one bigger thing that does all
>> that in an integrated fashion. to the point that even if the one
>> big thing would have nice,additional features, I would still opt
>> for the decomposed one.
> Well, you just now described systemd. The systemd project develops
> many small tools which do one thing ant interact together via
> defined interfaces.
> The init daemon is a bit more powerful that sysvinit, but it still
> only does what it is supposed to do: Starting, stopping and
> monitoring services. The other tools under the systemd umbrella do
> different things.

Is that really what the init daemon is supposed to do?

At a glance at the sysvinit source, it doesn't look to me like
/sbin/init itself does service management, in the "starting, stopping
and monitoring services" form; at most, it seems to handle some subset
of the "monitoring" part, in the form of noticing when something has
died abnormally. (Which goes well beyond just services, when necessary.)

From what I can see, it looks as if sysvinit's service management is
actually handled pretty much entirely by sysv-rc, which is not PID 1.

If that's correct, and if the systemd PID 1 binary handles service
management, then that's something it's doing which the init daemon
itself has not traditionally done. Which doesn't automatically mean that
it shouldn't, but which does seem to eliminate the argument that it
"only does what [the init daemon is] supposed to do".

Looking at the sysvinit source for this, and thinking about the
differences in relation to systemd, has led me to come up with some
ideas in regard to possible init-system-et-al. design which I think may
be interesting enough to be worth pursuing or at least discussing.
However, that discussion would cease entirely to be remotely on-topic
for debian-devel (even to whatever extent this entire thread isn't
already offtopic).

Any suggestions for a place where such discussion would be welcome or
at least acceptable, and where it would reach people who are
experienced with or at least interested in the design and
implementation of init systems? (I suspect that the systemd development
forums would satisfy the latter criterion but would not satisfy the

   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: