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

[Andrew Savchenko]

On Fri, 21 Feb 2014 16:40:46 -0600 Canek Peláez Valdés wrote:
> >>>> Of course the larger a project is the *potential* number of bugs
> >>>> increases, but so what? With enough developers, users and testers, all
> >>>> bugs are *potentially* squashed.
> >>>
> >>> Agreed, but I know of enough large projects with large development teams
> >>> and even more users that don't get the most basic bugs fixed.
> >>> Quantity is not equivalent to Quality.
> >>
> >> I also agree with that. My point is that the systemd project has
> >> enough numbers of *talented* developers to do it.
> >>
> >> You can disagree, of course.
> >
> > Talented developer, maybe.
> > But not talented designers.
>
> That's subjective. For me (and many others), the design of systemd is sound.

Thanks to your explanation of socket activation it is subjective no
longer. Systemd design flaws may be discussed in sheer technical
terms, see below.
 
> > If I were to have sockets created in advance (does it work with TCP/IP
> > sockets?) I would get timeouts on the responses which would lead to some
> > services not starting correctly and ending up in limbo...
>
> You don't know how the socket activation works, do you? At boot time,
> if a service ask for a socket on port 1234 (and yes, they work on
> TCP/IP sockets), systemd opens the socket for the service, and the
> service *does not start yet*.
>
> When the *first* connection gets into the socket, systemd starts the
> service, and when it finishes starting, systemd passes the opened
> socket to it as an fd. Done, now the service has control of the
> socket, and it will until the services terminates; not when the
> connection closes (although you can configure it that way), when the
> *service* terminates.
>
> If several connections arrive to the socket *before* the service
> finishes starting up, the kernel automatically queues them, and when
> systemd handles the socket to the service, the service does it things
> for all of them.
>
> There is *no single* connection lost. Well, if a godzillion
> connections arrive before the service finishes starting up, the kernel
> queue is finite and some would be lost, but it would have to be a lot
> of connections arriving in a window of some microseconds.

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.

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

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.

As one can see, while systemd socket activation design will work for
many case, 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).

Best regards,
Andrew Savchenko