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
(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.
EnvironmentFile= is pretty much always a bad idea, and we probably should never have added that, since it invites packagers to reintroduce the
/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.
In the daemontools world, we have environment directories of course, read with the
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.