There are a few possible sources of environment:
Environment= which lets you set variables
EnvironmentFile= which lets you load values from a file
PassEnvironment= which lets you define variables which should be passed from PID1.
- Static configuration (e.g.
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
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/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.