On Fri, Dec 28, 2012 at 5:23 PM, Kevin Chadwick <ma1l1i...@yahoo.co.uk> wrote: > On Fri, 28 Dec 2012 13:14:46 -0600 > Canek Peláez Valdés <can...@gmail.com> wrote: > >> On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick >> <ma1l1i...@yahoo.co.uk> wrote: >> > On Thu, 27 Dec 2012 17:38:15 -0600 >> > Canek Peláez Valdés <can...@gmail.com> 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 = start > /usr/bin/pkill sshd = 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. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
