[PUP-4460] 'statefile' is never pruned of files no longer in management Created: 2015/04/23  Updated: 2017/05/18  Resolved: 2017/05/15

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Eric Sorenson Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
duplicates PUP-3647 Puppet stores files forever in state.... Closed


The 'statefile' (state.yaml) never cleans up entries which USED to be under management but are no longer in the catalog. This causes the statefile to grow without cleanup, and there could be a bunch of extra work puppet does on intialization that could be totally unneeded.

I made a short gist that exercises the problem:


An interesting question that arose through this exploration: What is the purpose of the statefile? The setting help text is kind of untrue:

    # Where puppet agent and puppet master store state associated
    # with the running configuration.  In the case of puppet master,
    # this file reflects the state discovered through interacting
    # with clients.
    # The default value is '$statedir/state.yaml'.
    statefile = /opt/puppetlabs/puppet/cache/state/state.yaml

The master code does not refer to the statefile at all, however. And the only state that appears to be stored are checked and synced timestamps, which appear to be related to to scheduling and auditing (see resource_harness.rb:39) but the details are not clear to me.

Comment by Michael Smith [ 2015/04/23 ]

Adding a few more notes: in Puppet Apply scenarios, we load the statefile twice. For some reason, the 1st load (from configurer) is very quick, the 2nd load (in catalog#apply) is much slower.

Update: Side-effects of inserting a debugger. We do two loads, which is unnecessary, but the difference in performance seems to be due to loading the `byebug` debugger I was using.

Generated at Sun Jan 26 22:26:00 PST 2020 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.