== 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
../sysadmin/LANGHate]], 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.)