It seems a problem that init.d scripts inherit the PATH of their caller. It seems like runscript should be setting the PATH to the sane default obtained from profile.env. This is important because otherwise init.d scripts can fail unexpectedly, for example... sesame /proc/20820 # PATH=/ /etc/init.d/distccd stop /sbin/runscript.sh: line 1: cat: command not found /sbin/runscript.sh: line 198: cat: command not found /sbin/runscript.sh: line 205: rm: command not found * ERROR: "/etc/init.d/distccd" has syntax errors in it; not executing... Granted, this is a pretty contrived situation, but it demonstrates the problem. In my real-world situation, the problem was that distccd couldn't find gcc in its new location. Fetching the new environment settings from profile.env would have solved that issue. This should probably be the behavior for ALL init.d scripts. Aron
if you update/reemerge distcc it'll find gcc correctly a fix was added to get the path of gcc and passing it to distcc
Thanks for the distcc tip. However perhaps the example got in the way of the bug. It still seems wrong that init.d scripts inherit the PATH of their caller... Aron
Will be fixed on CVS shortly, should be in baselayout-1.8.6.3.
