I am trying to create a systemd service;

This service has a script that is supposed to use some environment variables;

So I created this:

cat /etc/systemd/system/atlantis-server.service 

Which points to this

pkara@atlantis-server:~$ cat /usr/local/bin/atlantis-server.sh 
source /etc/environment
atlantis server --atlantis-url="$URL" --gitlab-user="$USERNAME" --gitlab-token="$TOKEN" --gitlab-webhook-secret="$SECRET" --gitlab-hostname="$HOSTNAME" --repo-whitelist="$REPO_WHITELIST"

What I noticed (after some errors in my systemd logs) is that I had to explicitly source /etc/environment

(this is where the above vars are declared).

Why is this needed?

Aren't they globally visible?

edit: Adding this to the service definition did not solve the problem


5 Answers 5


/etc/environment is not a global configuration file.

It applies only on Linux; only to PAM sessions, as employed by login and so forth; and only in the case where a particular PAM plug-in is installed and enabled on the system, and where that PAM plug-in has not been configured to use some other file (because /etc/environment is merely its default if it is not told otherwise). It is that PAM plug-in that reads it.

Otherwise, it is just a meaningless file in /etc that nothing uses.

Whilst you could set environment variables globally in systemd-system.conf, this applies to all services, not just to the ones that you are wanting to change.

Similarly, whilst an EnvironmentFile in the appropriate service unit(s) is a way to have systemd read a common file with a list of environment variable definitions, the systemd people discourage its use. They regard EnvironmentFile as a bad idea, and its use as a mistake.

The proper way to do this per the systemd people is to set each variable in the service unit with an Environment setting, which contains the actual environment variable name and value to be set, not a filename. This can either be directly in the relevant service unit, if as here one is writing one's own service unit to be placed in /etc; or be in a .conf override file, if one is adjusting a pre-packaged service unit in /lib or /usr/lib.

Further reading


The following is offered to provide clarity on what /etc/environment is/does, when it's consulted and what package provides it:

whereis /etc/environment
environment: /usr/lib/environment.d /etc/environment

Feeding the results of whereis above, we confirm /etc/environment is a SystemD file:

sudo dpkg -S /usr/lib/environment.d
systemd, snapd: /usr/lib/environment.d

Consulting man environment.d, we are told the purpose of /etc/environment:

"The environment.d directories contain a list of "global" environment variable assignments for the user environment. systemd-environment-d-generator(8) parses them and updates the environment exported by the systemd user instance to the services it starts.... For backwards compatibility, a symlink to /etc/environment is installed, so this file is also parsed."


As you can see from the previous answer - Systemd doesn't source that file when launching a service.

Adding this to the service definition did not solve the problem

Environment is used for inline definition of envvars (ex. Environment=KEY1=Value1). To read from a file use EnvironmentFile directive. The file that EnvironmentFile points to should be in following format:


It shouldn't contain any shell substitutions or variable interpolations because Systemd is not a shell and can't handle that info properly.


Add the following to your service configuration:


@jeff-schaller please note this is not Environment= but EnvironmentFile= so you should not have deleted my answer. Indeed my answer does result in the variables from /etc/environment being made available to the service.


No, environment variables is per-thread property, so no globally visible, just inherited from some parent or grandparent process. Systemd don't read that file when launching system service.

You must log in to answer this question.

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