The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #5246

Puppetd does not remove it's pidfile when it exits

Added by R.I. Pienaar over 5 years ago. Updated over 4 years ago.

Status:ClosedStart date:11/09/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:agent
Target version:2.7.10
Affected Puppet version:2.6.2 Branch:
Keywords:mcollective

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

When running puppetd it should delete its pid file when it exits

root     20572  2.0  0.5 116736 35256 ?        Ss   23:10   0:00 /usr/bin/ruby /usr/sbin/puppetd --onetime --splaylimit 30 --splay

The pid file /var/run/puppet/agent.pid would have 20572 as expected, the puppet run completes ok:

Nov  9 23:11:27 xen1 puppet-agent[20572]: Finished catalog run in 19.68 seconds

But it leaves the pid file on the disk after exiting


Related issues

Related to Puppet - Bug #2888: puppetd doesn't always cleanup lockfile properly Needs More Information 12/04/2009
Related to Puppet - Bug #12188: agent when run --no-daemonize tries to remove the pid of ... Closed 01/26/2012

History

#1 Updated by Andrew Forgue over 5 years ago

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.

#2 Updated by Andrew Forgue over 5 years ago

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.

#3 Updated by Nigel Kersten over 5 years ago

  • Status changed from Unreviewed to Accepted
  • Priority changed from Normal to High
  • Target version set to 2.7.x

#4 Updated by R.I. Pienaar about 5 years ago

  • Keywords set to mcollective

#5 Updated by Hunter Haugen over 4 years ago

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.

#6 Updated by Hunter Haugen over 4 years ago

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.

#7 Updated by Anonymous over 4 years ago

  • Category set to agent
  • Priority changed from High to Normal

#8 Updated by R.I. Pienaar over 4 years ago

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.

#9 Updated by R.I. Pienaar over 4 years ago

  • Status changed from Accepted to In Topic Branch Pending Review

https://github.com/puppetlabs/puppet/pull/327

#10 Updated by R.I. Pienaar over 4 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

#11 Updated by R.I. Pienaar over 4 years ago

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..

#12 Updated by Anonymous over 4 years ago

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.)

#13 Updated by Michael Stahnke over 4 years ago

  • Status changed from Merged - Pending Release to Closed
  • Target version changed from 2.7.x to 2.7.10

released in 2.7.10rc1

Also available in: Atom PDF