15

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.

Improve this question

1 Answer 1

Reset to default
21

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
4
  • 3
    Thanks for the answer. This is rather unfortunate, as I thought having debian preinst maintainer scripts generating env files would be simpler than generating *.service files; that way the services would be static but their envs could change dynamically based on, say, the debian package name or packaging vars. Poettering has some very... erm.... interesting opinions on things.
    – Wimateeka
    Commented Jan 24, 2018 at 15:00
  • 3
    @Wimateeka I think what Poettering is saying here is that instead of debian maintainers deploying *.env files, they can deploy *.conf files as "drop-ins". While the downside involves prefixing [Service] to the file and Environment= to each line, the benefit is the *.conf files can be overridden by a local administrator.
    – Stewart
    Commented Feb 12, 2021 at 21:48
  • 5
    I disagree with EnvironmentFile= being a mistake, and I wish it included a more thorough argument. In my use case, I have multiple different apps which need to use the same variables, one of them is my Rails server which is run by a systemd service; another one of them is my Rails migrations which is run via a script instead. My Rails codebase needs access to the same variables, and it is sometimes used through Systemd, and sometimes via other means. That's why I'm considering using EnvironmentFile=/etc/environment.
    – Velizar Hristov
    Commented Nov 24, 2022 at 5:44
  • 1
    I'm facing a similar issue, I'm obliged to work on a systemd GNU/Linux distro, and this why I ended up here... I've tried things like EnvironmentFile=/etc/environment but unfortunately, it seems that the syntax of those systemd-styled EnvironmentFiles slightly differs from standard old-style pure UNIX-style configuration files, which can be also sourced from shell scripts. I had to find a way to work around this kind of "feature". Is it just me, or GNU/Linux was much simpler and UNIX-philosophy-compliant, about two decades ago?
    – Pierre
    Commented May 17, 2023 at 10:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .