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 9A2CE1381FB for ; Sat, 29 Dec 2012 01:08:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 253CE21C05F; Sat, 29 Dec 2012 01:08:16 +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 BF5BB21C032 for ; Sat, 29 Dec 2012 01:06:48 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id z13so9333573iaz.31 for ; Fri, 28 Dec 2012 17:06:48 -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=4P2jV4f8d9mwhU3GZTWAszqZxEhdVKmkuQWHiFcY7J0=; b=XBNOzHG64sNYcqJCSehXoPLDqlS3MfjuS7YsrZlhsFekXh92JsC7gZZQeWC19qZnhU 8VoDpCr6gxLZqAXemuGp7ux+dAC6wZ4SIR569DJ1uKewg6MA5Gl3fiG+GCbxoU3mEieX gWygl2kJ0bSJJpKYpMIqkBYZWOCYn1NVT/t4otr7CmdSGLa3vx2xjCCUQygGxpIR6723 xXf4uV8V/xER450L2lRc18bu5n7xzzGYEcNYTJRqgP05e45evepU8ulQ7HYm6qSq0kOf Jo1azC5a+JlMPKNuRCMOmhKqE48OD0xXOQZZAH59xMuSW2n0pGcVtOPCawHvKvDpOz1h Tg+Q== 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.89.163 with SMTP id bp3mr26197427igb.89.1356743208065; Fri, 28 Dec 2012 17:06:48 -0800 (PST) Received: by 10.64.32.195 with HTTP; Fri, 28 Dec 2012 17:06:47 -0800 (PST) In-Reply-To: <20121228232356.4880fe02@kc-sys.chadwicks.me.uk> References: <50CB1942.3020900@gmail.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> <20121228232356.4880fe02@kc-sys.chadwicks.me.uk> Date: Fri, 28 Dec 2012 19:06:47 -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: 4457ff4b-a1a3-44ad-a1c7-0e7393eaa1a5 X-Archives-Hash: d72858c4156d3e03fcea35ab30ead085 On Fri, Dec 28, 2012 at 5:23 PM, Kevin Chadwick wro= te: > On Fri, 28 Dec 2012 13:14:46 -0600 > Canek Pel=C3=A1ez Vald=C3=A9s wrote: > >> On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick >> wrote: >> > On Thu, 27 Dec 2012 17:38:15 -0600 >> > Canek Pel=C3=A1ez Vald=C3=A9s wrote: >> > >> >> In SysV, I can *write* the daemon in the init script. >> >> In *that* sense, the init system tells the daemon how to do things, >> > >> > Please explain, sure there is the environment that tells a daemon >> > what to do. No shell can tell a c daemon like sshd how to drop >> > priviledges or use systrace but it could do these things for it in >> > a more fine grained manner before it tries and fails itself or if >> > the daemon wishes it to like monit. It's still not telling how but >> > duplicating or removing the need. That's just a bonus that applies >> > to all init systems because shell is so powerful on unix. >> >> 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). >> > > That's what you meant, how disappointing. Yeah I've knocked up a few > very useful ones myself but call them scripts (Such as grepping logs or > dns servers and feeding real daemons with info). > >> You can't do that with systemd; there is a clear and unavoidable > > You can't is better is it? Yet you can exec a daemon written in shell > with systemd. > >> 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 > > With regular expressions to get the exact pid but > > /usr/sbin/sshd -f /etc/ssh/sshd_config =3D start > /usr/bin/pkill sshd =3D stop or many other incantations > > There are many tools that do this job just fine. If systemd just did > this and was there by default I would consider replacing monit with it. > Like a reliable root filesystem I want a reliable pid 1. > >> 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. With systemd, that possibility *doesn't exist* (because it >> doesn't uses a Turing-complete language to start/stop/monitor >> daemons). > > Doesn't frighten me one bit. I know the startup almost inside out of my > servers, doesn't take long on OpenBSD. On Linux it would take longer but > nowhere near reviewing systemd and knowing C has nothing to do with the > immediate control shell can provide under any init system including > systemd but the Turing complete argument is simply propaganda as well > as all the features to distract from the fundamental flaws in the > design of systemd. > >> >> 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. If you don't agree with that, >> well, we must agree to disagree. > > There is nothing else, you exec or parse a script or daemon just as > systemd does. The only difference is systemd tracking double forked > processes with cgroups and I have already provided a link that refutes > any point to do so. There are corner cases that are easily manageable > and it certainly isn't worth the sacrifice of POSIX compatibility and > so Linux applicability. Linus has said cgroups are a horrible > but necessary evil, which in my opinion means avoid them unless you have > no choice. There is a perfectly good and in my opinion superior > choice, but I love simplicity, it has served me well. I don't doub it. As I said, the only thing to do is to agree to disagree. 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