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 3E657138F15 for ; Sat, 22 Feb 2014 17:51:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BD361E0853; Sat, 22 Feb 2014 17:51:01 +0000 (UTC) Received: from mail-la0-f65.google.com (mail-la0-f65.google.com [209.85.215.65]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 791C4E0784 for ; Sat, 22 Feb 2014 17:51:00 +0000 (UTC) Received: by mail-la0-f65.google.com with SMTP id hr17so816097lab.4 for ; Sat, 22 Feb 2014 09:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=OrV3a1k/EXt87vQU+oY4gA6d4n+sTPo7W/XeKtqJyiI=; b=Hp7trRefyYRyXAmLjQ4K5hjO8Gpor5mF8a80YX8EJPZWbuUfYE4Szu4aB0kW9mOrsN mH5mItE7tKbepoJvhODIDNsxko/oJb2hX12FHL/k5klgbp/DHZemZnWKlSJ8thY5No9k A2JD6rTsSyEAeLdyFR5xV3goApXXenEoS/dnOhyO6THcO+BxBajPyivmCbMInOAYYFUp gdr//ss4DMiOuw5IplhEJZLWrgBk1SlSO8qARULlb5Gg1Pz/ptB2MHH2Qtht0sY30knc z1GyYNQHj2hKW7dsmRV/fRowz1aByW/z+nSolTzDCArYM9Qj1B/fhyKjoE0nv9BBNiBR /9yQ== 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 X-Received: by 10.112.172.98 with SMTP id bb2mr1747333lbc.69.1393091458671; Sat, 22 Feb 2014 09:50:58 -0800 (PST) Received: by 10.114.170.67 with HTTP; Sat, 22 Feb 2014 09:50:58 -0800 (PST) In-Reply-To: <20140222192821.fbb1f68742e46459b1c87cb1@gmail.com> 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> <20140222192821.fbb1f68742e46459b1c87cb1@gmail.com> Date: Sat, 22 Feb 2014 11:50:58 -0600 Message-ID: Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 641e12b1-afee-4b09-b517-e879ba396f2f X-Archives-Hash: 9747fc22c26b07759666f1f1e740874d On Sat, Feb 22, 2014 at 9:28 AM, Andrew Savchenko wrote= : [snip] > 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. 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 --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico