I am currently rewriting upstart jobs to use systemd and I wanted to know:

where is the "default" place to an EnvironmentFile?

It could potentially go in /etc/environment

It could be with all the other service files in /etc/systemd/service, /run/systemd/system or /lib/systemd/system but I don't see any other EnvironmentFiles in these locations for any other Service.

I've also debated /etc/default/ or /etc/<PACKAGE_NAME>

There is no documented "conventional" place to put it. Many of the examples I've seen seem to use /tmp/<FILE_NAME> which makes no sense as /tmp is wiped on reboot, and those files need to persist so they can be referenced whenever the Service is started or restarted.

Background: I am generating the EnvironmentFile at preinstall time (with maintainer scripts) before the debian package is installed, and I know the file must be available every time the service is started/restarted.


Someone else answered this question here on the Unix & Linux Stack Exchange site.

(Excerpt below)

The systemd people do not like environment files.

So there isn't one.

Several of the systemd people are on record, over the years, as saying that environment files are a mechanism that they should never have given to systemd in the first place.

The native systemd mechanism is, after all, the service unit file itself, wherein environment variables are set with Environment= keys. Customizing the environment of a service with administrator-defined or machine-specific variables is, in their view, a matter of dropping in snippet .conf files for units, that set other environment variables with further Environment= keys.

(But honestly, there's really no point in trying to dynamically convert stuff into a file that is suitable for EnvironmentFile=. […] Also /etc/sysconfig is a Redhatism that should really go away, the whole concept is flawed. Adding a new /run/sysconfig/ certainly makes that even worse.)

I probably should never have added EnvironmentFile= in the first place. Packagers misunderstand that unit files are subject to admin configuration and should be treated as such, and that spliting out configuration of unit files into separate EnvironmentFiles= is a really non-sensical game of unnecessary indirection.
— Lennart Poettering (2015-12-09). Query regarding "EnvironmentFile". systemd-devel.

Use of EnvironmentFile= is pretty much always a bad idea, and we probably should never have added that, since it invites packagers to reintroduce the /etc/default/ and /etc/sysconfig/ madness we try to remove.
— Lennart Poettering (2015-07-22). please consider having variables for an entire unit file. systemd bug #618. GitHub.

Bonus content

In the daemontools world, we have environment directories of course, read with the envdir/s6-envdir command. Albeit that it is not a standard nor a requirement of daemontools, a convention that one can use, that aligns with some tools, is that the environment directory is named env and lives in the service directory alongside the run program and other stuff.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.