2011-12-09
A quiet advantage of the systemd approach to service management
One of the ways that things like systemd and upstart are different
from the traditional /etc/init.d approach to starting and restarting
services is in who starts and restarts services. In the traditional
approach, you do this directly by running /etc/init.d scripts (either
explicitly or through some cover scripts). In the systemd world, things
are indirect; 'systemctl start foo.service' just asks the master
systemd to run the appropriate commands to start the service.
There is a somewhat subtle advantage to having systemd do this, one that I have been quietly appreciating lately: your shell environment never leaks into restarted services.
In the init.d world, a manually started or restarted service inherits
whatever environment your shell had when you ran the script(s),
especially your environment variables. This is different than init's
environment and can quite possibly contain settings that will change how
the service operates.
(Even logging in directly as root or using 'su -' doesn't
necessarily make this concern go away. As we've seen before, locale settings can drastically change the
behavior of programs and ssh will helpfully propagate your current ones
to the remote end.)
The systemd approach makes all of those concerns go away. The
environment you run systemctl or initctl in doesn't matter, because
all these commands do is ask the master process to do things. The
master process doesn't inherit anything from you and so the commands
it runs are uncontaminated by whatever weird environment you run
stuff in. Instead they're guaranteed to always be running in the same
environment regardless of whether they were started at boot time or
stopped and restarted later.
This issue is somewhat near and dear to my heart because I retain a
fairly customized environment even when I su to root. On init.d
systems, I need to go out of my way to make sure that things like
mailers and sshd will inherit as few peculiar things as possible (and
I'm sure I'm not always successful). On systemd systems, well, I can
forget about the whole concern. I enjoy that.
(There are sometimes drawbacks to this approach; for example, you can't quickly increase the number of open file descriptors a daemon can have by changing your root shell's ulimit and then restarting the daemon, or set special debugging flags in the environment. I haven't found these drawbacks to be an issue in practice so far.)
(This entry was brought to you by me spending a bunch of time today
going 'systemctl restart ...' to test some things.)