Puppet

I have seen this before as well.

0,30 * * * * /usr/local/bin/puppet agent --splay --onetime >/dev/null 2>&1

However it seems to be an issue if the catalog finished before the next cron run, but the report is bing submitted.

Here’s a rudimentary timeline..

   :00 - puppet agent --onetime --splay
   :29:00 - catalog retrival
   :29:56 - catalog finishes
   :30 - puppet agent --onetime --splay (Run of Puppet configuration client already in progress; skipping)
   :30:xx - report submitted, original process ends

From here, puppet will never run again and I have to manually delete the pid file.

I’m not sure if this is the same issue as RI, but it’s the first one that showed up when searching and sounded familiar.

The PID that winds up in the /var/lib/puppet/run/agent.pid is the pid from the run at :30:00 in my above example.

Currently confirmed on Puppet 2.6.4 shipped with PE 1.2 as well as the last merge of 2.7.x, commit 25213bfcd0c3bf1b5b59131d91490268b4949374.

• If puppet agent --onetime is run, it drops a pid file and doesn’t clean it up.

• If puppet agent --onetime --no-daemonize is run then it never places a pid file.

• If puppet agent is forked into the background and killed via kill then it cleans up its pid file.

The onetime method in lib/puppet/application/agent.rb calls @agent.run which daemonizes and creates the PID, but then just exits with 0, 1, or :details_exitcodes instead of agent process or calling @daemon.stop.

If you call @daemon.stop right before if not report (line 324) then it seems to be the desired behaviour, but I haven’t thoroughly search out the matter.

I concur with Hunter, have tested (actually didnt see his comment and came to the same fix independently)

Add @daemon.stop(:exit => false) before the checks on report and the various exit code behaviors in the Puppet::Application::Agent#onetime method and that sorts it all out.

Dan: I just noticed I did that onto 2.6.x, how do we ensure this also go into 2.7.x? New to the process and all..

R.I. Pienaar wrote:

Dan: I just noticed I did that onto 2.6.x, how do we ensure this also go into 2.7.x? New to the process and all..

Best practice is to commit to the oldest version you want to include the fix. We merge all changes up on a regular basis, 2.6 –> 2.7 –> telly, so it will get merged up soon. (Before the next 2.7 release, specifically.)