Project:Systemd/conf.d files

The systemd project unit files guidelines state that conf.d files must not be used through EnvironmentFile= in unit files. This article aims to explain why.

What to do instead

Instead of using conf.d files, provide sensible defaults, but if required, create an example override configuration file in /etc/systemd/service. See the systemd ebuild policy for further details.

Incompatible file format

While the format used by conf.d files and EnvironmentFiles may seem similar, those files are only partially compatible. The conf.d files are pure shell scripts that are executed by openrc using the administrator's shell of choice. The service files are parsed as configuration files using minimal, .desktop-alike syntax.

So while even the default conf.d file may work properly with systemd, the one modified by local system administrator may actually prevent the service from starting. In particular, systemd will not perform any variable substitution and it will not handle any shell syntax other than simple single value assignment. Such tricks were perfectly fine in conf.d files.

Limited abilities of handling multiple variables

conf.d files often used multiple variables to enable additional options in daemons. For example, /etc/conf.d/alsasound states:

FILE /etc/conf.d/alsasoundExample impossible-to-use conf.d file from ALSA

# RESTORE_ON_START:
# Do you want to restore your mixer settings?  If not, your cards will be
# muted.
# no - Do not restore state
# yes - Restore state

RESTORE_ON_START="yes"

# SAVE_ON_STOP:
# Do you want to save changes made to your mixer volumes when alsasound
# stops? 
# no - Do not save state
# yes - Save state

SAVE_ON_STOP="yes"

Since systemd service files have simple, declarative syntax they do not support conditionals based on values of conf.d-set variables. In other words, the unit file would need to spawn shell specifically to check the value of those variables which is an overkill.

Inconsistent system configuration handling

As proved above, not all conf.d files may be used properly with systemd. Moreover, many packages provide upstream systemd files which -- obviously -- do not use Gentoo-specific /etc/conf.d directory.

Having some of unit files use configuration in /etc/conf.d and some others elsewhere is confusing to the system administrator. While supposedly all packages install files in /etc/conf.d, some of those file are actually used only in OpenRC and therefore ineffective to systemd.

Other reasons to avoid configuration in unit files

Configuration split between multiple layers

In the most common case, the daemon spawned by service has a configuration file. Having extra configuration in service splits the configuration between the init system and the dedicated configuration files unnecessarily. Choosing a single location for configuration is better.

All variables are exported

It should be noted that Environment= and EnvironmentFile= keys were not designed to make unit files configurable but to allow exporting environment variables needed for programs. Therefore, all variables declared there are exported into the environment of spawned program. This may result in exposing configuration data to third parties.