From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 3873D138EFB for ; Sat, 22 Feb 2014 15:29:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 33BA8E0C71; Sat, 22 Feb 2014 15:28:51 +0000 (UTC) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B8825E0C06 for ; Sat, 22 Feb 2014 15:28:49 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id gl10so578022lab.28 for ; Sat, 22 Feb 2014 07:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type; bh=y44ktaYb7PstyfTLi9bSDTL6rGa9mDdiCle14YCg6PM=; b=Ab8Z70Wnk8SyZW//sI2MpTqxN78023d4dqCg5ZvCHBkT2R1+0YMCt9UfWYBZKU5p3Q NRDY06OafBLCYo9tGevMP4eIM27C5K57TWi5AIF8He3G3VSv2QcNSim8GB86Bha8db/9 7IJ2AheIj+d/xHD4+SbovHFP1AVh45WebwSvLq2OTy6HkQsuTbSK9b9SthUGNHp5gSr2 CJOs1U91XiUIPAvE/BVp4uKDB87g5toQmQiaAw9ulyVYGn31hO/DFMKRNQYd4rZvlzKt JvLkofYr2+c2ns9rDvNzsUQpsHnPSyqjBQR7dCUJG6x6pAquWXvH8C68vgngFWI+h6m8 wDVw== X-Received: by 10.152.219.37 with SMTP id pl5mr7320461lac.36.1393082927961; Sat, 22 Feb 2014 07:28:47 -0800 (PST) Received: from localhost ([198.46.152.80]) by mx.google.com with ESMTPSA id qx7sm11650850lbb.9.2014.02.22.07.28.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Feb 2014 07:28:45 -0800 (PST) Date: Sat, 22 Feb 2014 19:28:21 +0400 From: Andrew Savchenko To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie Message-Id: <20140222192821.fbb1f68742e46459b1c87cb1@gmail.com> In-Reply-To: References: <52FF84CE.2050301@libertytrek.org> <201402152023.10543.michaelkintzios@gmail.com> <5300DD51.5060207@libertytrek.org> <53010A8E.2050909@googlemail.com> <53012691.6040503@googlemail.com> <20140217215255.5766cb026df2f0b8002f8702@gmail.com> <20140218203656.abace1d77731d845bec62c62@gmail.com> <4ba5b05280a16043f9898e32b68049a7.squirrel@www.antarean.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Sat__22_Feb_2014_19_28_22_+0400_7R_B43dWxkb77RuQ" X-Archives-Salt: ffe0d174-6662-4bf7-877a-516323ee4c77 X-Archives-Hash: a0f685616c65ee348508578fc373324f --Signature=_Sat__22_Feb_2014_19_28_22_+0400_7R_B43dWxkb77RuQ Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 21 Feb 2014 16:40:46 -0600 Canek Pel=C3=A1ez Vald=C3=A9s wrote: > >>>> Of course the larger a project is the *potential* number of bugs > >>>> increases, but so what? With enough developers, users and testers, a= ll > >>>> bugs are *potentially* squashed. > >>> > >>> Agreed, but I know of enough large projects with large development te= ams > >>> 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. >=20 > That's subjective. For me (and many others), the design of systemd is sou= nd. Thanks to your explanation of socket activation it is subjective no longer. Systemd design flaws may be discussed in sheer technical terms, see below. =20 > > 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... >=20 > 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*. >=20 > 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. >=20 > 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. >=20 > 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 --Signature=_Sat__22_Feb_2014_19_28_22_+0400_7R_B43dWxkb77RuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJTCMIoAAoJEFZZU7lTcnVsvv8P/Aj4odXdbqbKXyL8qyVwSSTP 4ny3Yt1rqbHquuqZTVe3Uwv0JbE9GL3fyLsy5xnWeyLmQufJULDCYd4U0zW0/3S8 hRUZgOQJr2YduVCWe7hEPLRsgbZ0dWfH5In3Kyb9Ble7J8vIn4ZvM7TjuXZHoVZq maf9Qa5X8mP96GPVeEZYRgrbvSk3z8hPOq3BjKm4ZUG6Rg91A4SprKJ+Ff5fEwhC EngRXBUpPUoTkyJOg3WDQe7jtZtdd0cdrGczNJe6V78KuMEDeAMXPhQzzC34ZI0t wFiLjag/4lay1mHpql4jN9V9CJ0Iqft/AvRdSGGqVWqr4Wd94PL2gKEuksaPrZZ3 dvb41c27LmKykdI0zyAmbz3J6HlEy96asfkdGZEYJLyMamySs2YZvviTtV+hjZSq D+dyp0vJ/WcZWFYq2c1lK4/HygstFgOfUla3y5XQ6KqgVNfHHFzbEXksz0AnEqQ7 jQVLn+gD5dgR+Xw7gTxRtRfg3Gw5p6fgJY+5rL3hsW4do4auGygeJ4EGWwmcZMPF p67VExdSpfhWknNy5bUGJ+MWnVnOdUfVUuJAaCMtsu7y3INtQeYtJ6nDLAag7gHV k3/IESbhSsUB2NoSft3HKwsOUWd65S0CNqe2tdLcJL6VYFtRzq124UR2otgZtp05 xMXGFHTkkV9Fq+L6I47U =V97w -----END PGP SIGNATURE----- --Signature=_Sat__22_Feb_2014_19_28_22_+0400_7R_B43dWxkb77RuQ--