Hi Ian, Ian Jackson <ijack...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
