Make systemd service inherit environment variables from /etc/profile.d

Question

I have a systemd service running under a specific user.

I erroneously assumed that the service would have access to the environment variables all users inherit from scripts/exports under /etc/profile.d

Is there a way to accomplish this without having to manually copy the variables in systemd unit file definition.

For example, I have the following

$ cat /etc/profile.d/somexports

export VAR1=VALUE1
export VAR2=VALUE2

Can this be passed / exported to a systemd service?

Answer 1

There are a few possible sources of environment:

1. Using Environment= which lets you set variables
2. Using EnvironmentFile= which lets you load values from a file
3. Using PassEnvironment= which lets you define variables which should be passed from PID1.
4. Static configuration (e.g. $USER)

It might sound like EnvironmentFile=/etc/profile.d/someexports is what you want, but that's not the case. /etc/profile.d/* is often sourced by your shell and can be parsed by your shell. systemd is shell agnostic and so it will not rely on bash syntax. The EnvironmentFile should contain new-line-separated variable assignments which is much stricter.

systemd's design discourages dynamically changing units or their environments. Even the EnvironmentFile= option was only added as a result of pressure and was later considered to be a mistake by systemd's developers. One example of this design is that $PATH does not affect which binaries are used. This keeps things more deterministic as when you define a unit, you are defining everything about how that unit should run without worrying about external influence.

So short answer is: No. you cannot load /etc/profile.d/* into systemd and that's intentional.

But the answer you probably want is: yes, you can load it. You just need to run your application through a shell.

You can do that by changing:

ExecStart=/usr/bin/myservice

To

ExecStart=/usr/bin/bash -lc myservice

That will cause bash to be the parent process, which loads /etc/profile.d/ and forwards that environment to its child. Also note that I did not specify a full absolute path to myservice. In this case, myservice will be based on $PATH and that may or may not be /usr/bin/myservice. You can see how this might make things more difficult to troubleshoot and that's the disadvantage of going this route.

Answer 2

I think this is addressed as follows

ExecStart=/bin/sh -lc /path/to/binary

The -l flag makes the shell invocation a login shell. We need this because only login shells source profile scripts.

$ bash --help | grep -- -l
GNU bash, version 4.4.12(1)-release-(x86_64-pc-linux-gnu)
    --login