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 B4DBE1381FB for ; Fri, 28 Dec 2012 20:18:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 961A521C09B; Fri, 28 Dec 2012 20:18:41 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E2D5921C09B for ; Fri, 28 Dec 2012 20:17:34 +0000 (UTC) Received: from mail-pb0-f46.google.com ([209.85.160.46]:45831) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1TogN8-000yp6-1e for gentoo-user@lists.gentoo.org; Sat, 29 Dec 2012 03:17:38 +0700 Received: by mail-pb0-f46.google.com with SMTP id wy7so6097516pbc.33 for ; Fri, 28 Dec 2012 12:17:32 -0800 (PST) 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.66.88.129 with SMTP id bg1mr101339768pab.71.1356725852942; Fri, 28 Dec 2012 12:17:32 -0800 (PST) Received: by 10.68.248.66 with HTTP; Fri, 28 Dec 2012 12:17:32 -0800 (PST) Received: by 10.68.248.66 with HTTP; Fri, 28 Dec 2012 12:17:32 -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: Sat, 29 Dec 2012 03:17:32 +0700 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=f46d042dff5185b29e04d1ef5a57 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: svr-us4.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Archives-Salt: c2d2011a-225c-4998-b2a7-ef9fa2fd1ce4 X-Archives-Hash: 2733aa55a241294a244bd7144562695b --f46d042dff5185b29e04d1ef5a57 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. 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) and pepper the code with asserts and instrumentation. 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. 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 because 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 do some changes, and all is well. 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 find out what happened. We made changes. It works again. In the two examples I give, having a C program doing all the starting will certainly mean that complex things have to be done, not to mention the headache of compiling them -- and possibly fail. sh scripts are much easier to modify. > 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. Rgds, -- --f46d042dff5185b29e04d1ef5a57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 29, 2012 2:18 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" <caneko@gmail.com> 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<= br> > sense, the init system (which uses shell for launching daemons) can be=
> used to determine *how* the daemon behaves (because it uses shell for<= br> > 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.

SysAdmins, especially Enterprise SysAdmins, will prefer total control of= the startup process. If a daemon is extremely important for enterprise ope= ration, any SysAdmin worth his/her salary will fire up vi (or emacs) and pe= pper the code with asserts and instrumentation.

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.

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 because = the dev *needs* the features only available in the new version. We check th= e (extremely) detailed logs. We find out what made the package balked. We d= o some changes, and all is well.

Another example: After a security audit, we are required to upgrade a ce= rtain 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.

In the two examples I give, having a C program doing all the starting wi= ll certainly mean that complex things have to be done, not to mention the h= eadache of compiling them -- and possibly fail.

sh scripts are much easier to modify.

> Like the clear separation between content and presentation in webap= ps,
> 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&= #39;s Law reigns supreme.

Rgds,
--

--f46d042dff5185b29e04d1ef5a57--