We have all been there. You update a script or a binary, tweak the EnvironmentFile, and trigger a restart. Everything looks green in systemctl status, but your application starts behaving like it is running on a different planet. You check the code, you check the config, and you eventually realize that systemd didn’t actually pull in the variables you thought it did. It’s a classic case of assuming the init system reads your environment files the same way your shell does, which is almost never the case.

The trap of environment file syntax

Systemd does not run a shell when it parses an EnvironmentFile. It expects a simple key=value format. If you try to do clever things like referencing existing variables or using command substitution, systemd will treat those as literal strings. Most people don’t realize this until they see their database connection string literally containing the string $PASSWORD_ENV instead of the actual secret they set in their profile. It fails silently, and your logs end up full of authentication errors that make no sense.

systemctl show-environment --property=EnvironmentFile

• EnvironmentFile directives are not shell scripts so avoid backticks and dollar-sign variable expansion
• Use absolute paths because systemd will not assume the file is in your home directory or current working directory
• Add a hyphen prefix to the path if you want systemd to ignore the file entirely if it happens to be missing

Verifying what actually made it into the process

When you are deep in the weeds, stop guessing what the service sees. Use the proc filesystem to peek into the process’s actual environment memory. Grep through the environ file of your running pid to see exactly what key-value pairs the kernel has handed the process. This beats staring at unit files every single time.

If you are still hitting walls, check if your service file uses DynamicUser or PrivateTmp, as these settings can isolate your service from global environment state more than you intend. Next time you are debugging a mystery configuration issue, check the process environment before you rewrite your entire application initialization logic.