Systemd should follow the shell's default behavior of expanding nonexistent environment variables to nothing, within the context of a .service file (e.g. ExecStart). Rationale: I have a daemon which sources an EnvironmentFile. The EnvironmentFile defines a variable which isn't required for normal behavior but which, if set, needs to be passed as a startup parameter in ExecStart. For example: [Service] ... EnvironmentFile=/etc/conf.d/sshd ExecStart=/usr/sbin/sshd -D $SSHD_ARGS ... If SSHD_ARGS is unset, it appears to be passed to /usr/sbin/sshd literally which then fails to start. This would be alleviated if systemd were to expand unset environment variables to a null string.
I think I may be misunderstanding the way the ExecStart command is being handled. Is there no environment variable expansion at all?
There is env var expansion, in two syntaxes: $foo as a single word will be replaced by the contents of $foo split up at whitespaces as several arguments. And ${foo} may appear as part of another word (or seperately) and will be replaced by the contents for $foo, but not split up. Note however that env var expansion is (currently) not supported on the binary path itself, only on its contents.
Created attachment 38523 [details] [review] Strips quotes in variables read from EnvironmentFile
Ok, I've narrowed this down to an issue with quoting. In the EnvironmentFile in question, I have: SSHD_ARGS="" ...which is interpreted literally as "". I've attached a patch which fixes this, but it takes a sledgehammer approach to a 10 cent nail. the unquote() function in util.c is probably a better choice, but it doesn't appear to work as I'd like it to (I'm unsure of the behavior of strdup when its passed an empty string).
This is fixed in v16.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.