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@lists.gentoo.org/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
pgphWTsbn3Qsg.pgp
Description: PGP signature
