[Discuss] SysVinit vs. systemd

[smallm at panix.com (Mike Small)]

Bill Ricker <bill.n1vux at gmail.com> writes:
> I found one blog that seems to have a history of level-headed advocacy
> for systemd without insulting people or SysV Init (says it isn't badly
>  broken). It's not by a SystemD DEV but by a working sysadmin.
>
> http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon?showcomments
> & http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight

Some of the points in the latter seem only to apply when comparing with
upstart. Comparing to rc or sysvinit scripts, the points that seem 
relevant are these:

"systemd handles a lot of annoying infrastructure for you; for example,
you do not have to arrange to daemonize programs you run."

I don't understand this at all. Aren't daemons written as daemons
(giving up controlling terminal and whatever else within their own
code).

"systemd starts and restarts services in a consistent and isolated
environment, not in whatever your current environment is when you run
the start and restart commands."

Sounds like a plausible problem. runit also advertises this as
important. I'd need to experience a gotcha to appreciate it. The current
environment when daemons start on my machine is predictable. It's the
environment that the rc scripts run in, that was brought about by
init/getty/login. If it's messed up, the scripts have a bug that need
fixing. When I'm doing something weird and adhoc, probably I'm using
sudo or su -l to root. In both cases the environment is slim and
controlled, particularly with sudo.

"systemd keeps track of what processes belong to a particular service,
so it can both list all the processes that are part of a service and
tell you what service a particular process is part of. This is a boon to
manageability."

I can imagine this being a problem for someone doing something
serious. For little old me, the set of daemons is on the order of 10 and
completely recognizable by name in the cases where related processes
have different process groups. But this is thinking more in terms of
automated management maybe. More below.

"because it actively tracks unit status, conditional restarts are not
dangerous; it shares this behavior with any competently implemented
active init system."

Don't understand this. What's a conditional restart and why is it
dangerous? What's the difference between an active and passive init
system?

"it apparently does per-user fair share scheduling by default (but I
haven't had a chance to run systemd in a situation where I could really
see this in action)."

There's only one of me (though I do use two sometimes three non-root
users cause I don't trust firefox and some other programs). But yeah, I
could imagine admins liking this.


The part about being able to properly identify related processes by
their cgroup tag seems the strongest point, or at least most interesting
to me. Before leaving for work I looked on my own systems for multiprocess
daemons.

On Slackware I only found two: udev and sendmail. The two udev processes
had the same process group id, so a cgroup shouldn't be necessary for
relating them back to each other. The sendmail processes didn't though,
so I looked at the rc script to see what its restart command did:
killall sendmail, just what Lennart opens with as the worst possibility
here: http://0pointer.de/blog/projects/systemd-for-admins-4.html 
On the other hand I'm not sure when a person would restart sendmail
using the rc script. If you change the config file you're supposed to
send the process from the pid file a HUP (or isn't there a command you
can run to do the right thing for you now?).

On my openbsd system there are a lot of multiprocess daemons cause they
privilege separate everything needing root. But almost all of the
related daemons share a pgid. The only exception was dhclient. I
couldn't figure out with a quick look where dhclient gets killed or
restarted in init scripts. It's started in OpenBSD's netstart script
when it sets up an interface needing dhcp. You can run this script over
and over again without issue. (I often run it cause the wireless card on
that machine, or its driver, doesn't work well and needs resetting.)
Hmmm, maybe dhclient doesn't need outside management.


Question: Here...
http://0pointer.de/blog/projects/systemd-for-admins-2.html 
... as he works up to how he uses cgroups identifying child processes he
never mentions process groups as an option, only the parent id. Why
don't multi-process daemons always keep the same process group and use
that in scripts that kill/restart? It seems indeed that they don't all
do that, looking at sendmail and dhclient on my systems.

But even accepting that pgid isn't a universal option and conceding that
cgroup is handy for this, how hard would it be to change your init
script to start the troublesome daemon or two with a separate cgroup
tag? There seems to be a cgexec command for this and other commands to
look at cgroup tags of processes, so those of us running traditional
shell script based inits could go in and add this feature right now if
we ran into a problem with killall, say (I'll tell you why frictionless
shifters are better than indexed on bicycles or why power windows on
cars are dumb but I'm not going to try to defend killall). Should take
like five minutes or so, right?

-- 
Mike Small
smallm at panix.com