Issue #5224 has been updated by Nigel Kersten. Assignee changed from Nigel Kersten to Daniel Pittman
I'm not in favor of us adding more configuration options for this behavior, but I'm ok with "having a blacklist of things to remove because they are now totally wrong". ---------------------------------------- Bug #5224: puppetd does not set environment correctly from Exec https://projects.puppetlabs.com/issues/5224 Author: Simon Mudd Status: Needs Decision Priority: Normal Assignee: Daniel Pittman Category: exec Target version: Affected Puppet version: 0.25.5 Keywords: exec,crontab,service,environment,HOME Branch: It's possible to run a script using Exec. This can sometimes cause confusion if the environment is not set correctly. It's not terribly clear to me exactly what environment the user should expect when running Exec. This should be better documented if nothing else. In any case I see on a box we use to run puppet: # ps auwx | grep puppetd root 25736 0.1 0.1 173072 78728 ? Ssl 04:02 0:52 /usr/bin/ruby /usr/sbin/puppetd --logdest=/var/log/puppet/puppetd.log root 30268 0.0 0.0 61148 756 pts/0 S+ 14:11 0:00 grep puppetd # strings /proc/25736/environ SHELL=/bin/bash MAILTO=root USER=root PATH=/sbin:/usr/sbin:/bin:/usr/bin PWD=/ LANG=en_US.UTF-8 HOME=/ <======== started at boot and HOME here is _not_ root's HOME directory. SHLVL=6 LOGNAME=root _=/usr/sbin/puppetd # Now if I restart puppet using service(5) or directly with /etc/init.d/puppet restart I get different results: ### Using service(5) # service puppet restart Stopping puppet: [ OK ] Starting puppet: [ OK ] # ps auwx | grep puppetd root 13089 1.8 0.0 128100 35264 ? Ssl 14:24 0:00 /usr/bin/ruby /usr/sbin/puppetd --logdest=/var/log/puppet/puppetd.log root 13158 0.0 0.0 61148 756 pts/0 S+ 14:25 0:00 grep puppetd [root@bc29bprdb-01 ~]# strings /proc/13089/environ TERM=xterm-color PATH=/sbin:/usr/sbin:/bin:/usr/bin PWD=/ LANG=en_US.UTF-8 SHLVL=2 _=/usr/sbin/puppetd # cat /etc/redhat-release CentOS release 5.4 (Final) ### Using /etc/init.d/puppet # /etc/init.d/puppet restart Stopping puppet: [ OK ] Starting puppet: [ OK ] # ps auwx | grep puppetd root 14328 3.0 0.0 128108 35272 ? Ssl 14:26 0:00 /usr/bin/ruby /usr/sbin/puppetd --logdest=/var/log/puppet/puppetd.log root 14808 0.0 0.0 61148 752 pts/0 S+ 14:26 0:00 grep puppetd [root@bc29bprdb-01 ~]# strings /proc/14328/environ HOSTNAME=xxxxxxxxx.xxxxxxx.com TERM=xterm-color SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=10.111.22.33 38508 22 SSH_TTY=/dev/pts/0 USER=root LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35: SSH_AUTH_SOCK=/tmp/ssh-GrzGm30026/agent.30026 MAIL=/var/spool/mail/root PATH=/sbin:/usr/sbin:/bin:/usr/bin INPUTRC=/etc/inputrc PWD=/root LANG=en_US.UTF-8 SHLVL=3 HOME=/root LOGNAME=root SSH_CONNECTION=.... LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/usr/sbin/puppetd # This box runs CentOS Linux and root's home directory is /root. The end result is that the environment may vary quite considerably depending on the precise puppetd innovation. Looking at the service man page in Linux (RH's is a bit vague) or better still FreeBSD's which does the same you see it says: ENVIRONMENT When used to run rc.d scripts the service command sets HOME to / and PATH to /sbin:/bin:/usr/sbin:/usr/bin which is how they are set in /etc/rc at boot time. This makes sense as during startup the only filesystem and directory you can be sure to exist is /. I'd suggest that the environment is set prior to using Exec as follows being compatible with crontab(5): Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, PATH is set to /usr/bin:/bin, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner. HOME, PATH and SHELL may be overridden by settings in the crontab; LOGNAME may not. (Another note: the LOGNAME variable is sometimes called USER on BSD sys- tems... On these systems, USER will be set also). This behaviour seems standard in Linux and the various BSD flavours. That is while you can't expect many environment variables to be set when running Exec you do expect $HOME to be set, $SHELL and that's about all. The fact that $HOME is not set correctly broke several scripts which assumed that as it was defined it was correct. Specifically MySQL access it's default configuration file ~/.my.cnf to determine how to access the server. With puppet started at bootup HOME was incorrect set and this is the value passed on to the root user. Note: this issue has taken a while for me to figure out as restarting puppet on CentOS where I use it if done via /etc/init.d/puppet would make puppet pick up the new $HOME value of /root and then it would work properly and if using service(5) I would get different results. Again in both cases these results are also different from the behaviour if puppet starts on bootup. References: * http://www.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+8.1-RELEASE&format=html * http://www.freebsd.org/cgi/man.cgi?query=service&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html While it is possible to set the environment in Exec (I don't see examples of how to do this in http://docs.puppetlabs.com/references/stable/type.html#exec) it also seems sensible to document the behaviour and make it consistent irrespective of how puppetd is started. cron' default behaviour seems like a reasonable starting point. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
