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 29E8B1381FB for ; Fri, 28 Dec 2012 20:38:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D939721C165; Fri, 28 Dec 2012 20:37:59 +0000 (UTC) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 00D0E21C15C for ; Fri, 28 Dec 2012 20:36:51 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id z13so9209693iaz.31 for ; Fri, 28 Dec 2012 12:36:51 -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=8Fd5AiuP2vgZk72ibD/BkZgdfjroj3hJiW7nW5wMOi0=; b=oVezCvD7LOrMipLNSXewA5XqnW01RjCxFI0dyIMmtFOYhHdeWc0biR/aOjgiUXsUgU /m1RH0tYJ8IRYsJ0SGuhC0r6Nn+1IwneXYRlp/tKrVvAYA6yaX8FFQqqfAZTxggvFBJG Tpn5XHOH1v0lAgR0ioRmLS7bGBcRtSetSNV9PNcK+p6efL7FThn3Gx9gYaUHG7PEzht8 qN67dpn1XPo+lUkU8qGmtQAbzbW8ezR+Pqq0JF8jwJQVk64tFP8WPonuw7viIiHhX66d ZRAoJowX5vfl8idMsTqbqXy+KhYVXVdip7r5aCqWajNgEWy2hHVdDy5Ovh4qqdH3Mavn wcAg== 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 Received: by 10.50.53.161 with SMTP id c1mr24773029igp.95.1356727011217; Fri, 28 Dec 2012 12:36:51 -0800 (PST) Received: by 10.64.32.195 with HTTP; Fri, 28 Dec 2012 12:36:51 -0800 (PST) In-Reply-To: References: <50CB1942.3020900@gmail.com> <20121217104621.735bf43a@khamul.example.com> <20121218163332.7956f31a@khamul.example.com> <87txrd6pb3.fsf@ist.utl.pt> <20121223182037.1553813f@khamul.example.com> <87bodk7lb6.fsf@ist.utl.pt> <20121224085528.56f535ec@khamul.example.com> <50D85167.9060309@gmail.com> <20121224204817.335033c6@khamul.example.com> <50D957F0.1060406@gmail.com> <20121226221950.04342909@kc-sys.chadwicks.me.uk> <420952.15724.bm@smtp140.mail.ukl.yahoo.com> <20121228185322.2ec34bcc@kc-sys.chadwicks.me.uk> Date: Fri, 28 Dec 2012 14:36:51 -0600 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit? 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: e8df6836-de77-42e7-927b-74c50c4662c0 X-Archives-Hash: 13369e24dccec210641fb8cfddaf4416 On Fri, Dec 28, 2012 at 2:17 PM, Pandu Poluan wrote: > > On Dec 29, 2012 2:18 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" wrote: >> >> Stop thinking in sshd. I can write the *whole* daemon in shell, not in >> another script file, but inside /etc/init.d/mystupiddaemon (or >> /etc/rc.whatever); shell is Turing-complete, I can write in it >> anything I can write in C (or in assembler, or machine code). In that >> sense, the init system (which uses shell for launching daemons) can be >> used to determine *how* the daemon behaves (because it uses shell for >> launching daemons). >> >> You can't do that with systemd; there is a clear and unavoidable >> separation between the starting/stoping/monitoring of daemons, and the >> daemons themselves. Such distinction doesn't really exists in SysV nor >> OpenRC (since they use shell, a Turing-complete language, for >> launching daemons), and therefore you can mixup everything. I agree, >> it doesn't necessarily means that it *will* happen; but even the >> possibility is frigthning for a system administrator in a production >> server. > > You got it wrong. I don't believe so. > SysAdmins, especially Enterprise SysAdmins, will prefer total control of = the > startup process. If a daemon is extremely important for enterprise > operation, any SysAdmin worth his/her salary will fire up vi (or emacs) a= nd > pepper the code with asserts and instrumentation. Pandou, I have worked as SysAdmin. Several years. "Total control" has degrees; if you program in assembly language, you have even more control. And with systemd you can still fire up vi or Emacs (or, if you prefer "total control", ed), and fix *your* daemon. If systemd has a bug, you can still look at the code, and fix *that* code. What you say doesn't make any sense: "any SysAdmin worth his/her salary will fire up vi (or emacs) and pepper the code with asserts and instrumentation" works in SysV, OpenRC, systemd, and anything else as long as you have the source code. The only problem resides in proprietary code. > Having a Turing-complete language for starting a script is one of our (= =3D > Enterprise SysAdmins) weapon for fixing up glitches due to some changes > introduced by the package maintainer. Again, you make no sense: you can fix "glitches" as long as you have the source code. You can roll your own packages (I maintain my overlay to get rid of OpenRC on my systems). That some SysAdmins can *only* code properly (if at all) in shell is a problem of *those* SysAdmins. A worthy SysAdmin, if encountering a bug with systemd, can easily check out the C code and fix it (it's relatively simple, not kernel-level). And having a separation between the starting/stoping of daemons and the daemons themselves makes it easier to check where the bug lies, and fixing accordingly, instead of patching blindly to workaround the real problem. > An example: A dev needs a newer version of a package. We upgrade it. It > refuses to startup properly, but going back is out of the question becaus= e > the dev *needs* the features only available in the new version. We check = the > (extremely) detailed logs. We find out what made the package balked. We d= o > some changes, and all is well. How that is not possible in systemd? > Another example: After a security audit, we are required to upgrade a > certain daemon to a new version, despite the current version running well= . > As we feared, the new version can't start. We use the detailed log to fin= d > out what happened. We made changes. It works again. How that is not possible in systemd? Have you ever used it? > In the two examples I give, having a C program doing all the starting wil= l > certainly mean that complex things have to be done, not to mention the > headache of compiling them -- and possibly fail. You are assuming the problem is going to be in systemd's side. First of all, that will not always be the case. Second, if it is the case, you go and fix it. You still have the code. SysAdmin's laziness is not an excuse to do things wrong. It's also "more complex" to add comments to the code, it's "more complex" to take notes of the procedures rolling servers, it's "more complex" to keep a database of the versions running in each machine, and what hardware has and when it was installed. It's always "more complex" to properly do the job. > sh scripts are much easier to modify. Read above. >> Like the clear separation between content and presentation in webapps, >> or between the model and the view in the MVC design patter, having a >> clear separation between how you start/stop/monitor your daemon, and >> what the daemon does, is a good thing. > > That is the Theory. In Practice, things don't work that way. Murphy's Law > reigns supreme. Then we should agree to disagree in this particular issue. Regards. --=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