[Discuss] SysVinit vs. systemd

Robert Krawitz rlk at alum.mit.edu
Fri Sep 12 12:31:12 EDT 2014


On Fri, 12 Sep 2014 12:07:29 -0400, Mike Small wrote:
> 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).

You might have a program that can be run both interactively and as a
daemon (I have a transparent proxy that can be used in this way).  And
that daemonization code can be buggy in each daemon.

> "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.

Maybe and maybe not.  It depends upon how root's .bashrc (or whatever)
is set up.  But this does contain quite a bit of user-level stuff:

$ sudo env
root's password:
TERM=xterm
LC_COLLATE=POSIX
LANG=en_US.UTF-8
DISPLAY=:0
XAUTHORITY=/home/rlk/.Xauthority
COLORTERM=1
SHELL=/bin/bash
MAIL=/var/mail/root
LOGNAME=root
USER=root
USERNAME=root
HOME=/root
PATH=/usr/bin:/bin:/usr/sbin:/sbin
SUDO_COMMAND=/usr/bin/env
SUDO_USER=rlk
SUDO_UID=nnn
SUDO_GID=mmm

> "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.

My laptop has a few dozen daemons running on it; some of them aren't
that obvious to me.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

MIT VI-3 1987 - Congrats MIT Engineers 6 straight men's hoops tourney
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



More information about the Discuss mailing list