Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] SysVinit vs. systemd

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:

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

MIT VI-3 1987 - Congrats MIT Engineers 6 straight men's hoops tourney
Tall Clubs International  -- or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --
Project lead for Gutenprint   --

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

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /