Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Kevin Chadwick]

On Fri, 28 Dec 2012 13:14:46 -0600
Canek Peláez Valdés <caneko@×××××.com> wrote:

> On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick
> <ma1l1ists@××××××××.uk> wrote:
> > On Thu, 27 Dec 2012 17:38:15 -0600
> > Canek Peláez Valdés <caneko@×××××.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.