Issue #3757 has been updated by Jeff McCune.
Status changed from Merged - Pending Release to Re-opened
Assignee set to eric sorenson
Eric, I'm re-opening this issue because it's targeted at 3.0.0, set to merged
pending release, and causes a user-facing regression with respect to 2.7.x.
While working on #2888, I've observed a regression of the following scenario in
3.0.0-rc6-164-g7a7f676 with respect to 2.7.19-170-gf0ef301
When configuration runs are deadlocked because of #2888, `puppet agent
--enable` does not break the deadlock. In Puppet 2.7.x `puppet agent --enable`
does break the deadlock and allows configuration runs to happen again.
I'm hoping that however we fix #2888 will also fix this scenario with `puppet
agent --enable` in Telly, but I think it's important to re-open this since we
think we're done with this issue and we've actually regressed in one aspect.
Steps to reproduce:
<pre>
$ catalog_lockfile=$(puppet agent --configprint agent_pidfile)
$ touch ${catalog_lockfile}.blank
$ mv ${catalog_lockfile}{.blank,}
$ puppet agent --no-daemonize --verbose --runinterval=1
</pre>
You should see:
<pre>
Run of Puppet configuration client already in progress; skipping
Run of Puppet configuration client already in progress; skipping
Run of Puppet configuration client already in progress; skipping
Run of Puppet configuration client already in progress; skipping
</pre>
This is the exact situation that will eventually arise in #2888 when Puppet
agent is running as a daemon and run interactively.
I consider this ticket to regress with respect to 2.7.x because in 2.7.x,
`puppet agent --enable` clears the deadlock and in Telly, it appears to do
nothing.
----------------------------------------
Feature #3757: --enable and --disable should be improved
https://projects.puppetlabs.com/issues/3757#change-71090
Author: R.I. Pienaar
Status: Re-opened
Priority: Normal
Assignee: eric sorenson
Category: executables
Target version: 3.0.0
Affected Puppet version: 0.25.4
Keywords: mcollective enabledisable
Branch: https://github.com/puppetlabs/puppet/pull/680
At present the --enable/--disable and associated checks on the puppetd is all
done via a lock file /var/lib/puppet/state/puppetdlock.
My investigations reveal the behavior of this file to be:
* if exist and it's empty, someone ran --disable
* if exist and it's got a PID in it puppetd is doing a manifest run at present
* if it's absent its enabled and not running
The problem comes when you want to disable the daemon while it's running a
manifest. The lock file with PID in it will remain in place and once puppetd
is done doing its run it will remove the lock file, leaving your client enabled
when infact it was asked to disable the client and not run in future.
So I want to be able to disable future runs even while a current run is
happening. The easiest might be to have 2 lock files - one to indicate
enabled/disabled and one to indicate running dont start another concurrent run.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
