RFE: support specifier expansion for first word of ExecStart= directives

[spiette]

How to reproduce:
In a unit file, get an ExecStart directive like this:

ExecStart=/opt/%i/bin/service --args

It doesn't work, as documented (systemd.service(5): "Note that the first argument of the command line (i.e. the program to execute) may not include specifiers.", but the error message is cryptic.
Because systemd doesn't honor unit template specifier, the only option is to use another binary to spawn the process. For example, one can start it with

ExecStart=/bin/sh -c "exec opt/%i/bin/service --args"

which is not a contribution to the Zero Shell Project (http://0pointer.de/blog/projects/the-new-configuration-files).

The expected behaviour would be to support the specifiers in the executable name.

[poettering]

There's a technical reason for this: selinux linux in some cases requires us to know the binary to invoke before a unit instantiated for the first time, so that the right label can be derived for sockets. That's why we prohibit this in general. I am not sure we can really change that without compromising on the SELinux logic.

[evverx]

Actually, the program to execute may include specifiers (that bug was fixed by bd1b973).
See #2646 (comment)

[DrYak]

Hello !

I'm on Debian 8 Jessie - and that one ships with a version that doesn't seem to expand specifiers in executable name.

In addition to the shell-trick mentioned by @spiette, there's another one that I use:

ExecStop=/lib64/ld-linux-x86-64.so.2 /usr/local/bin/%i-cli stop

I'm simply manually running the ELF-interpreter. (Basically the same idea as manually running /usr/bin/perl script.pl instead of trusting the she-bang of the script)

Any idea when/if there will be official support for specifiers expansion in systemd? At least for specifiers than can be statically determined in advance by systemd (like template, machine, etc.)

[rektide]

Been working around lack of %h by calling /usr/bin/env everywhere, but doesn't feel great (having to set SyslogIdentifier= isn't fun). And it still presupposes that you've figured out how to setup PATH in your user session (systemctl --user import-environment PATH). It'd be really appreciated by user session folks if they had an effective way to share ~/ based scripts among themselves; currently requires manual intervention for each and every user (manually setting homedir in ExecStart, or env/PATH hackery), and that's slowing down user session adoption.

[james-lawrence]

@poettering would this issue be a good one for a new contributer to work on? I might be willing to put some time towards getting it implemented.

[keszybz]

Yes, a patch for this would be welcome. The tough part would be figure out how this interacts with selinux, i.e. no selinux checks should be called with the unexpanded path.

[r14c]

@pottering I don't see how permitting specifier expansion makes a difference, you have to resolve them before the command is useful in any case.

[gnat]

This is a big hangup for newcomers @poettering Think of it this way- most everyone who gets into writing .service files wastes hours on this conclusion in hopes of getting %h or some form of variable working in ExecStart= especially useful for --user userland systemd.

Collectively this must add up to 100,000+ hours of wasted time. Maybe there should be an effort to improve systemd ergonomics here and truly address the SELinux issue.

[keszybz]

Oh man, aggressive commenting on a issue that was closed five years ago is also not a best way to improve anything. The way that ExecStart works is now quite a bit more flexible compared to the state 5 years ago.

[gnat]

Correct me if I'm mistaken, but the main reason why this feature is important is because one cannot write portable userland .service files with ExecStart pointing to user binaries such as in /home/USER/.local/bin. This is essential for portable rootless services.

The way that ExecStart works is now quite a bit more flexible compared to the state 5 years ago.

If this was resolved somehow I'd like to know because I've just encountered this in 2021.

Should I be opening a new issue?