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

Re: piece of mind

On 10/21/2014 at 10:35 AM, Matthias Urlichs wrote:

> Hi,
> The Wanderer:
>>> Can you give an example of people doing that in case of systemd?
>>> Because so far, everything I heard was similar to GNOME, where:
>>> • systemd provided a feature.
>> This is the problem. The init system should not be providing
>> "features" which other software might, post-boot and pre-shutdown,
>> want to make use of.
> Define "post-boot". What about socket activation? Or starting up my
> database when the iSCSI link to the storage comes up, instead of
> *whenever*? Or cleanly restarting my Apache heap-of-processes?

None of those things are done exclusively at boot / shutdown time, so
they should not be done by the init system. If they are done at all,
they should be done by something which can run and do them under any
init system.

> Please explain why it should *not* provide these "features". Why
> should every daemon (or its startup script) re-implement the same
> code to put itself in the background, change UIDs, resource-limit
> and security-enhance (private /tmp) itself,when the same thing can
> be implemented once, so that I as a sysadmin (or my puppet script)
> don't have to learn ten separate ways of configuring that?

I never said every daemon, et cetera, should reimplement those things.
They shouldn't.

Those things should be implemented centrally, in something which can
work irrespective of the current init system. (Barring possibly a
hypothetical init system which actively tries to prevent it from working.)

> There are a bunch of things systemd can do which sys5rc can't do. Why
> is it a "design flaw" to provide these in the way that's easiest to
> implement, and therefore (presumably) least buggy?

Because, since there is only one slot for PID 1 per system, having
something depend on a feature that is provided by PID 1 breaks choice.
(This is an overly simplistic answer, but I've spent half an hour
writing possible more-detailed responses to this so far, and none of
them seem both accurate and unlikely to be misconstrued.)

Note that I (think I) would have no objection to providing such features
both in PID 1 (for its own use) and in an init-system-independent
external process, with PID 1 providing them for use by other things only
if and as no external provider is available. (In fact, if I'm
understanding things correctly, systemd itself used to do it that way
with cgroups management until the kernel upstream decided that having
multiple cgroups managers running at once was broken design and would
not be supported.)

Something vaguely like that is what seems to be being worked towards
(with some current success) by the systemd-shim project, which is
something of a kludge, and will inevitably be chasing whatever interface
changes systemd upstream chooses to make. It would be better design to
decide to provide that separate implementation as part of the main
project itself (in terms of maintenance, not necessarily of
integration), rather than as a third-party backfill.

>> The decision to incorporate such features into systemd is IMO the
>> design flaw which leads to the problems to which people object.
>> That decision was made by the systemd developers
> for a couple of reasonably good reasons. You might want to debate
> the validity of these reasons and the difficulty of doing it some
> other way, assuming that there's a tangible benefit of doing it
> another way in the 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.

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.

> "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.

And it's not an argument I'm making, at least not at present.

I'm not aware of what those reasons are, unless you're referring to the
points referenced in the systemd position statement which Josselin
quoted. My response to that is that "do it this way" vs. "do it some
other way" ignores the possibility of "don't do it at all", which may be
the correct choice in some cases.

   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: