1

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 
[Service]
ExecStart=/usr/local/bin/atlantis-server.sh

Which points to this

pkara@atlantis-server:~$ cat /usr/local/bin/atlantis-server.sh 
#!/bin/bash
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

Environment=/etc/environment
7

/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

1

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:

Key1=Value1
Key2=Value2

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

1

The following offered to provide clarity on what /etc/environment is/does, when its' 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."

Hope this cleared up any confusion. I know I was scratching my head a bit initially before I dug a bit deeper... ;-)

-1

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.

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.