setting PATH in init scripts
Hi,
[ This topic has been discussed before. However, I think it hasn't
come to a clear decision. ]
Problem is: what should init scripts (scripts in /etc/init.d) assume of
their environment, and/or what behavior should they have in
environments which aren't sane. In particular, what should they do
when the PATH doesn't contain binaries they invoke.
This question arises from #262224, and you'll find a starting point for
this discussion in the bug report logs. A good lecture is quoted, it
is a previous discussion of this problem in april 1999:
<http://lists.debian.org/debian-policy/1999/04/threads.html#00143>
(The original problem was posted in debian-devel:
<http://lists.debian.org/debian-devel/1999/04/thrd2.html#00812>.)
I also quote the current Debian Policy in the bug report, but I might
have forgotten some sections, please correct me:
"Now looking at the Debian Policy, section 9.3 isn't really
informative about what to do with the PATH or other environment in
/etc/init.d/* scripts.
9.9 tells us programs should not depend on environment variables to
function properly, and we should use reasonable defaults.
However, in 6.1, which doesn't directly relate to /etc/init.d/*
scripts, but talks about shell scripts in general, we read:
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, install-info, and update-rc.d can be found via
the PATH environment variable. Those programs, and any other program
that one would expect to be on 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."
Below I am numbering the points taken, and assigning letters to the
proposed actions, so you can react on a number instead of repeating
it's text.
Actions that could be taken
A) Augment the policy to require a sane environment when calling an
init script.
B) Augment the PATH in init scripts to be sure it contains at least the
required directories, for example: ``PATH="$PATH:/sbin"''.
C) Set the PATH unconditionally, to make sure it contains the required
directories, for example:
``PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"''
D) Use full pathname of binaries when invoking them from an init
script.
Interesting points made during the various discussions
1) There is no policy right now, all init scripts behave differently.
2) You can use a wrapper to setup a sane environment if your init
script assumes a sane environment.
3) 6.1: "Programs called from maintainer scripts should not normally
have a path prepended to them." (Of course, this is different from init
scripts, but it still suggests a nice behavior.) dpkg checks for a sane
PATH prior to calling maintainer scripts, and hence init scripts called
from maintainer scripts can assume a sane environment.
4) init sets a sane PATH at startup, see init(8), and all programs
inherit from init.
5) Other variables than PATH are affected, for example TZ or IFS.
6) If every script stores its PATH settings, it's hard to update a
global system PATH.
I would personnally add that:
- invoke-rc.d is a key script that doesn't touch the PATH right now,
but could be used to setup a sane environment if we required one ;
- /etc/init.d/skeleton should expose the target behavior we seek, right
now it hardcodes a PATH setting.
Regards,
--
Loïc Minier <lool@dooz.org>
PS: I am not a DD.
Reply to: