A quiet advantage of the systemd approach to service management

December 9, 2011

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

Written on 09 December 2011.
« Another reason sysadmins should program
ZFS pool activation and iSCSI (part II) »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Dec 9 00:06:53 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.