The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Puppet master not logging to file
|Assignee:||Brian Pitts||% Done:|
|Affected Puppet version:||2.7.12||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
I’m running puppet 2.7.12 on CentOS 5.8. I’m having trouble getting the puppet master to log to a file. The same configuration is working fine for the puppet agent. A single line is written to the master’s log file when it starts. When logging to syslog or the console, I get lots of output each time an agent talks to the master. When logging to a file, I get nothing. The master does not even appear to have the log file open. Below is my configuration and some shell output demonstrating the problem.
$ egrep -v '#|^$' puppet.conf
[main] vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl pluginsync = true factpath = $vardir/lib/facter autoflush = true [agent] server = redacted classfile = $vardir/classes.txt localconfig = $vardir/localconfig listen = false [master] modulepath = redacted storeconfigs = true dbadapter = sqlite3 dblocation = $vardir/storeconfigs.sqlite certname = redacted
$ egrep -v '#|^$' /etc/sysconfig/puppet
$ egrep -v '#|^$' /etc/sysconfig/puppetmaster
$ ps -wwfp $(pgrep -fd, puppet)
UID PID PPID C STIME TTY TIME CMD root 12566 1 6 18:33 ? 00:00:53 /usr/bin/ruby /usr/sbin/puppetd --logdest=/var/log/puppet/agent.log --verbose puppet 15612 1 5 18:43 ? 00:00:15 /usr/bin/ruby /usr/sbin/puppetmasterd --logdest /var/log/puppet/master.log --verbose
$ sudo pkill -SIGUSR1 puppetd
$ sudo ls -lt /var/log/puppet/
total 25136 -rw-rw---- 1 puppet puppet 25661723 Apr 6 18:51 masterhttp.log -rw-r--r-- 1 root root 21638 Apr 6 18:51 agent.log -rw------- 1 puppet puppet 3889 Apr 6 18:44 rails.log -rw-r--r-- 1 root root 68 Apr 6 18:43 master.log -rw-r----- 1 root root 4850 Apr 4 17:02 http.log
$ sudo cat /var/log/puppet/master.log
Fri Apr 06 18:43:43 -0400 2012 Puppet (notice): Reopening log files
$ sudo tail -n 1 /var/log/puppet/agent.log
Fri Apr 06 18:51:47 -0400 2012 Puppet (notice): Finished catalog run in 11.73 seconds
$ sudo fuser -s /var/log/puppet/agent.log; echo $?
$ sudo fuser -s /var/log/puppet/master.log; echo $?
#4 Updated by Brian Pitts over 3 years ago
Short version: puppetmasterd creates the log file with root ownership, but it should be owned by puppet.
I collected the information I filed in this issue on the same day that I tried and failed to get the master logging to a file. When I couldn’t get that working, I switched back to syslog. One piece of information I collected was that master.log was owned by the root user.
Since then, logrotate ran. It renamed master.log to master.log.1 and recreated master.log. When creating master.log, it gave ownership to the puppet user, as specified in /etc/logrotate.d/puppet.
Now that master.log exists and is owned by puppet, if I run
puppetmasterd --logdest /var/log/puppet/master.log the log messages are now being written to that file.
If I stop puppetmasterd, delete master.log, and then start puppetmasterd, master.log is owned by root and is missing the log messages again.
#5 Updated by Brian Pitts over 3 years ago
I’ve submitted a pull request which I fixes this in my testing. It’s at https://github.com/puppetlabs/puppet/pull/774
In Puppet::Application::Master I saw that the puppet master created the log file (line 19) before switching users (line 180). It shouldn’t be a problem to open a file as a more privileged user and continue to write to it after switching to a less privileged one, but for some reason in this case it is preventing further log messages from being written to the file. The pull request doesn’t solve whatever the underlying problem is, it just papers it over by changing ownership of the log file.
#6 Updated by Anonymous about 3 years ago
- Status changed from Needs More Information to Code Insufficient
This should probably be tolerant of failures to set the mode: rather than aborting if the user or group specified doesn’t exist, or if the chmod fails for some reason, this should continue on, I think.