On Tue, 11 Oct 2016 16:36:08 +0200
Andy Mender <andymenderunix_at_gmail.com> wrote:
> Dear Jan, Laurent,
>
> Thank you kindly for answering my questions and clarifications :). I'm
> slowly starting to have a general idea of how to use runit,
> but I will definitely have streams of questions in the nearest
> future. As far as I understood, the point is to avoid extensive
> scripting hodgepodge within run scripts to avoid replicating System V
> init limitations, correct?
I don't know that I'd phrase it like the preceding, but in fact my
average run script is 4 to 10 lines long, and my average sysvinit init
script (not written by me) is over 100 lines.
>
> Since dependency resolution is not done by runit, any inter-daemon
> communication is down to the capabilities of individual daemons,
> right? Case in point, if a specific daemon "talks" to another daemon
> via dbus, none of the runit programs care about this, because the
> daemon should know how to "do the talking" itself, right?
I guess the preceding is a true statement, but please keep in mind the
kind of person using a lightweight init: Epoch or daemontools-inspired,
would not want daemons "talking to each other" except in extreme
necessity, any more than you would put numerous gratuitous global
variables in a program you write so the objects and functions can "talk
to each other." In fact, modularity implies that interprocess "talking"
happens only in a well defined manner, for a very good reason.
Dbus is a traffic circle enabling everyone to talk to everyone else,
making debugging more difficult.
>
>
> Finally, in the systemd-sphere there is some emphasis on cgroups and
> socket activation. How relevant are those features in your opinion?
Cgroups is a feature that produces benefits in limited situations. The
Freedesktop people use it to overcome problems in their desktop model
where processes a user creates can survive after the user logs out.
They use cgroups to prevent that. It could have been prevented other
ways. Also, there may be situations where you WANT processes you spawn
to survive your logout.
Remember xinetd superservers? "Socket activivation" is systemd's way of
doing the same thing, making (IMHO) "socket activation" a complexified
NIH knockoff.
In my opinion, except for the possibility of programs gratuitously
requiring socket activation, socket activation is irrelevant. IMHO,
cgroups are relevant in relatively rare instances, and are irrelevant
in most situations. We lived without them for years, no problem.
> Within the articles I read it was pointed out that cgroups are a
> kernel feature and there is a sizeable section of the kernel .config
> devoted to that.
> Thereby, in theory any init can take advantage of that. Is that
> correct?
You're correct that they're built into the kernel. I leave it to
others to comment on whether other inits actually take advantage of
them. I doubt there are many compelling situations in which you'd use
cgroups.
> What about socket activation?
Yeah, if you need a superserver, use xinetd, and forget about the
"socket activation" buzzword. Superservers were much more relevant back
in the day, when your resources were so paltry that you didn't want to
have a listener process running all the time just to service requests
that might come in only once a week. Today, that process is cheap
compared to resources, which is why superservers aren't used that much
anymore.
Andy, one more observation: I'd think twice about letting the systemd
project set your expectations for init system requirements. They use
cgroups for certain things, and advertise that as a great benefit. It's
not. They make up the term "socket activation" and advertise that if
an init system doesn't have it, that init system is ineffective. This
is false. Follow the money: Plenty of people benefit from systemd
displacing all other init systems, even if systemd is ineffective or
effective only as long as programmers are given a million or so dollars
a year to keep it running despite its crushing complexity. Do not let
the systemd talking points influence the features YOU want in an init
system.
SteveT
Steve Litt
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28
Received on Tue Oct 11 2016 - 16:48:52 UTC