Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sat, Feb 22, 2014 at 9:28 AM, Andrew Savchenko <bircoph@×××××.com> wrote:
[snip]
> And here we have a design issue. I already pointed this issue in this
> discussion:
> http://www.mail-archive.com/gentoo-user@l.g.o/msg144144.html
> Though it was completely ignored by you. I understand: it is easier
> to discuss design in terms of taste than in technical merits.

I'm sorry, I was not part of that particular subthread. You are wrong
anyway (see below)

> Systemd assumes that time required to start service is small (at
> microseconds scale). While this is true for widely used simple
> setups, this is not true in general case. Service may take seconds or
> even minutes to start up (good example are services depending on
> enterprise SAN or large databases).

Yeah; and systemd needs not to worry about that. The clients
connecting have to. Set the clients to wait a reasonable time, and
then everybody is happy.

> And because systemd never assumes
> it can take long time to start we have the following issues possible
> in general case:
>
> 1. Client connections are lost due to timeout when service takes
> long time to start. Systemd fakes service to be available while it
> isn't still. Thus systemd is not an option for production grade
> servers.

Again, you can configure that on the clients.

> 2. Even if connection timeout is not reached, requests may pale up and
> be lost. Loss trigger depends on memory available, thus systemd is
> not an option for both embedded setups and production server setups.

You realize that if it's embedded, it makes no sense that it receives
the godzillion connections necessary for the kernel queue to fill up?
And on big iron, you can define the size of the queue; in the kernel,
again, this has nothing to do with systemd. You don't even need to
recompile your kernel.

> As one can see, while systemd socket activation design will work for
> many case,

Glad to see you at least recognize this; but it can work for all
cases. It doesn't have to, though (see below).

> it will fail for corner ones and by no means can't be used
> in production (where this corner cases have a high chance to rise).

You evidently have no idea what are you talking about.

First of all, as I said, the "problems" you mention are not problems
at all, since slow starting services, by definition, have clients that
need to cope with the slow starting (and if they don't, it's a bug in
the clients); and because either you are embedded, and therefore you
don't expect a godzillion connections, or you are medium size or big
iron, and you set your queue size with a kernel knob to be as large as
necessary.

And secondly, even if those problems were real (which they are not),
socket activation *IS OPTIONAL*. It's a feature that systemd supports,
*if the admin wants to use it*. If you are in a corner case and you
cannot change the timeout of your clients (because they are
proprietary, for example), or you are constrained by memory (if you
are embedded but anyhow want to handle gracefully a godzillion
connections), THEN YOU DON'T USE SOCKET ACTIVATION.

"Problem" solved.

If you are *really* interested in learning about the advantages of
socket activation, read [1]. However, I'm sure that you will not, as
time and again in this thread you only have show that you are not even
willing to do your homework before you start ranting against systemd;
just like you did when you said that libsystemd.so was used in PID 1
[2] (which, of course, you conveniently ignored although I replied
specifically to you).

Therefore, I'm not going to waste more of my time arguing with someone
who doesn't even read the proper documentation.

I'm done with you in this thread.

Regards.

[1] http://0pointer.de/blog/projects/socket-activation.html
[2] http://article.gmane.org/gmane.linux.gentoo.user/272840
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México