The Puppet Labs Issue Tracker has Moved:

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 See the following page for information on filing tickets with JIRA:

Bug #15472

rewrite puppet agent

Added by R.I. Pienaar almost 4 years ago. Updated over 2 years ago.

Status:InvestigatingStart date:03/28/2011
Priority:NormalDue date:
Assignee:R.I. Pienaar% Done:


Target version:-
Keywords:backlog Affected mCollective version:

We've Moved!

Ticket tracking is now hosted in JIRA:

This ticket is now tracked at:


We have the ‘puppetd’ agent which comes from the days we still had a ‘puppetd’.

Much have changed and puppet 3 will make pid/lock handling a lot better so we should rewrite this agent:

  • disable/enable/status should support the locking improvements in #3757 including setting messages
  • the config keys should be sorted out to be consistently named
  • it should default to puppet 3 filenames, locations etc
  • status should use last_run_summary to provide a better status of last run
  • it should support more common flags especially environment, noop/no-noop/tags
  • it should potentially support getting some stats from the reports – this might be too slow
  • it should include the resource() data source to discover based on managed properties
  • it should include a puppet() data source that lets you discover currently running/enabled/disabled nodes as well based on things like values out of last_run_summary
  • it should have some data retrieval out of the last_run_summary showing some aggregate information like configversion, time perhaps with outlier detection


Bug #15468: puppetd configuration options name mismatchClosedBoyan Tabakov

Bug #13440: puppetd agent enable and disable should check if pid in p...ClosedR.I. Pienaar

Feature #15497: adjust mcollective agent 'puppetd lastrun' to report time...Closed

Feature #6865: Proposed patch to add support to puppetd agent extra comm...ClosedR.I. Pienaar

Bug #15192: To add "--noop" and "--no-noop" options for mcollective p...Closed

Bug #17470: puppetd agent should have better error detectionClosed

Feature #18664: Add the runall commandClosedR.I. Pienaar

Feature #18679: Create a new puppet commanderAcceptedR.I. Pienaar

Related issues

Related to Puppet - Bug #16125: Puppet running as windows service does not create pidfile Rejected 08/27/2012
Related to Puppet - Bug #2888: puppetd doesn't always cleanup lockfile properly Needs More Information 12/04/2009
Related to Puppet - Bug #16491: Create a standalone API to manage the Puppet lock files, ... Investigating 09/19/2012


#1 Updated by Pieter Loubser over 3 years ago

Puppet 3.0 behavior

When puppet daemon is running, /var/run/puppet/ exists and contains the daemon’s pid.

When an apply is happening, /var/lib/puppet/state/ exists and contains the process doing the apply.

When puppet agent is disabled, /var/lib/puppet/state/agent_disabled.lock exists an contains a JSON document –> {“disabled_message” : “Message”}.

#2 Updated by R.I. Pienaar over 3 years ago

There’s a rough first run through this at ripienaar/feature/master/15472:

  • supports lock message mco rpc puppet disable message=‘foo’
  • the status action is built around last_run_summary and all the new lock files
  • the last_run_summary returns some key extracted bits in the top of the structure and then the whole summary – this is to fit in with the design of summary plugins
  • there’s a utility class that takes care of all the puppet interactions and have a way to abstract unix and windows behaviours. the hope is this will lead to a requirement for the puppet team to build and maintain a library that does all this reusable by mco, monitor scripts and others
  • there is a puppet() data plugin
  • there is a resource() data plugin

Filed #16424, #16415, #16414, #16411, #16410 and #16409 as improvement/fixes to mcollective, mostly because I made lots of stupid mistakes and so found edge cases in recent features.

The data plugins allow for rich discovery:

For puppet proper we have:

mco rpc rpcutil ping -S "puppet().status=disabled" 

Other data available are things like applying, daemon_present, disable_message, enabled, lastrun, since_lastrun, status

For resources we have:

mco ping -S "resource('file[/srv/www]').managed=true"
mco ping -S "resource().count>300"

There is some data aggregation where useful:

Requesting status will show a summary of host many nodes are in each state:

% mco rpc puppet status 
Summary of Status:

    disabled = 1

Requesting last run summary will show averages of config retrieval, total resources and total time across the matched nodes:

% mco rpc puppet last_run_summary
Summary of Config Retrieval Time:

   Average of config_retrieval_time: 6.914976

Summary of Total Resources:

   Average of total_resources: 391.000000

Summary of Total Time:

   Average of total_time: 6.914976

No client side stuff done yet.

#3 Updated by R.I. Pienaar over 3 years ago

  • Status changed from Accepted to Investigating
  • Keywords set to backlog

putting this on the backburner till puppet has a API for lock/pid/runs management see #16491

Also available in: Atom PDF