I don't see how puppet changes the env. Try printing the ENV from puppetd on one of the systems that are failing.
ENV is a global hash, you should be able call each with a block to print to the logs. If we verify that the runtime has the appropriate user and path, that will be confusing, but if it isn't that explains the behavior and gives a bit more focus to the problem. On Thu, Nov 13, 2008 at 12:59 AM, martin <[EMAIL PROTECTED]> wrote: > > > > On Nov 13, 1:31 am, Luke Kanies <[EMAIL PROTECTED]> wrote: > > > It just uses the path from the environment. > > > But that doesn't explain that the below script fails to find > crontab :) > ---8<--- > #!/bin/sh > # > > PATH=/usr/bin:/usr/sbin:/sbin:/usr/sfw/bin:/opt/sfw/bin:/usr/ops/bin > export PATH > > CONF=/etc/puppet/puppet.conf > > PUPPETD=/usr/ops/bin/puppetd > > LAST=/var/puppet/log/last > LOG=/var/puppet/log/cron.`date '+%Y%m%d%H%M'` > > if [ ! -f $CONF ]; then > echo "Error: $CONF is missing" > exit 1 > fi > > if [ ! -f $PUPPETD ]; then > echo "Error: $PUPPETD is missing" > exit 1 > fi > > $PUPPETD --onetime --verbose --no-daemonize --trace --debug > $LOG > > rm -f $LAST > ln -s $LOG $LAST > ---8<--- > > > Should we look at having a default path? If so, how should it change > > per-platform, if at all? > > > What about allowing the user to set the path in puppet.conf? > > [puppetd] > path /usr/bin:/usr/sbin:/usr/foo:/usr/bar > > cheers, > /Martin > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
