[Pkg-systemd-maintainers] Bug#732981: Bug#732981: ExecStart et al should be capable of honouring PATH

[Michael Stapelberg]

Hi Ian,

Ian Jackson <ijackson at chiark.greenend.org.uk> writes:
> systemd.service(5) says:
>
>        ExecStart=
>            Commands with their arguments that are executed when this service
>            is started. The first argument must be an absolute path name.
>
> This should be capable of handling a bare command name, to be found in
> PATH.
I asked in #systemd on IRC about this.

Lennart replied that using $PATH makes it easy to end up running a
binary that is not the one the service file author had in mind.

Furthermore, it is hard to provide a consistent $PATH to all service
files, yet avoid deadlocks. An example he provided is having /usr/local
on autofs, which can cause deadlocks when used in $PATH.

Tollef also notes that we don’t use this mindset in all places either,
e.g. we don’t use /usr/bin/env in shebangs consistently.

udev rules are another place where absolute paths are used.

> Debian Policy requires (s6.1) package maintainer scripts to find their
> components via PATH.  This doesn't necessarily imply that an init
> system should, but the same rationale applies.

Quoting the paragraph that you refer to:

> Programs called from maintainer scripts should not normally have a
> path prepended to them. Before installation is started, the package
> management system checks to see if the programs ldconfig,
> start-stop-daemon, and update-rc.d can be found via the PATH
> environment variable. Those programs, and any other program that one
> would expect to be in the PATH, should thus be invoked without an
> absolute pathname. Maintainer scripts should also not reset the PATH,
> though they might choose to modify it by prepending or appending
> package-specific directories. These considerations really apply to all
> shell scripts.

I personally find this a bit thin on rationale. I.e. the policy only
states that one can expect certain binaries and that one should use
$PATH, but it doesn’t explain _why_.

Maybe you can clarify?

-- 
Best regards,
Michael