Okay I can now replicate it. Annoying.

I am not sure if this is related – i can make a new bug if you think it isn’t – but I am seeing similar notify issues:

puppet-agent[1723]: (/Stage[main]/Mcollective::Install/Puppet::Pkg[rubygem-stomp]/Package[rubygem-stomp]/ensure) change from 1.1.7-1.el5 to 1.1.8-1.el5 failed: Could not update: Failed to update to version 1.1.8-1.el5, got version 1.1.7-1.el5 instead at /etc/puppet/manifests/common/modules/puppet/manifests/pkg.pp:7
puppet-agent[1723]: (/Stage[main]/Mcollective::Install/Puppet::Pkg[rubygem-stomp]/Package[rubygem-stomp]) Scheduling refresh of Service[mcollective]
puppet-agent[1723]: (/Stage[main]/Mcollective::Service/Service[mcollective]) Triggered 'refresh' from 1 events

So here a package fails to install, it then still notifies the service and the service restarts

Additionally I question the ‘normal’ priority of this ticket, the dependency and notification system in puppet is key to everything, I’d consider these issues critical.

The above is from 2.6.6

Just to chime in, also affecting me on 2.6.6:

    
puppet-agent[9787]: (/Stage[main]/Exim4/Service[exim]) Dependency File[/etc/exim/exim.conf] has failures: true
puppet-agent[9787]: (/Stage[main]/Exim4/Service[exim]) Skipping because of failed dependencies
puppet-agent[9787]: (/Stage[main]/Exim4/Service[exim]) Triggered 'refresh' from 1 events

I’m also confused by the “normal” priority of this ticket. This seems like a pretty fundamentally broken piece of a pretty fundamental mechanism in puppet!

+1, heavily contesting the assertion the model is not broken. I think if you were to come up with a order of precedence then require should always win.

I too would like to contest the assertion that the model is not broken. This is so fundamental to how I need to use puppet that I may need to consider alternate products if this model is truly deemed correct. I concur that require should trump all and that it should be treated as a hard dependency, not just affect the “order of operations”.

Please also see #7486, which is looking more and more like a duplicate of this ticket.

Related issues¶

This has been a long standing issue that continually surprises people about Puppet.

Added related tickets:

• Ticket #7486
• Ticket #8372

I would also like to add that this is a problem in our environment (2.6.2-1). I’m trying to install a package and if package installs correctly it should notify the service. Unfortunately the package is not currently available and the install fails but the services are still being restarted. This is a Bad Thing :–)

Does the service require the package? The require should do the right thing.

Came across this class during training here at puppetconf attempting to validate the sudoers file in an example.

At least 3 seperate people in my class hit this issue – it’s very surprising and frustrating.

+1 on raising the priority back to urgent – this isn’t a POLA thing here – it seems to have been broken and I can’t see how fixing it would surprise people?

Here’s another simple test case that models what we were doing in class:

file{"/tmp/a": ensure=>present, content=>"Test", notify=>Exec['/bin/false']}
exec{"/bin/false": notify => File["/tmp/b"], refreshonly=>true}
file{"/tmp/b": ensure=>present, source=>'/tmp/a', require=>Exec['/bin/false']}

[root@localhost manifests]# puppet apply -v 5876.pp
info: Loading facts in facter_dot_d
info: Applying configuration version '1316532415'
notice: /Stage[main]//File[/tmp/a]/ensure: created
info: /Stage[main]//File[/tmp/a]: Scheduling refresh of Exec[/bin/false]
err: /Stage[main]//Exec[/bin/false]: Failed to call refresh: /bin/false returned 1 instead of one of [0] at /etc/puppetlabs/puppet/manifests/5876.pp:2
notice: /Stage[main]//File[/tmp/b]/ensure: defined content as '{md5}0cbc6611f5540bd0809a388dc95a615b'
notice: Finished catalog run in 0.24 seconds

This issue seems to be complicated by the overlay of signaling / refreshing on top of conventional resource synchronization. Tags and schedules are just cream on top.

Suppose, then, we look first at conventional syncronization. It seems reasonable and expected that

(1) no attempt should be made to synchronize a resource if any of its direct or transitive dependencies fail to synchronize.

Furthermore,

(1a) if no attempt is made to sync a resource, then it is not synchronized, even if it has an otherwise trivial synchronization action (e.g. an Exec with refreshony => true).

Since we’re ignoring signaling for the moment, the dependencies in question are expressed only via ‘require’, ‘before’, and the non-signaling chain operators. I think this much works reliably.

It also seems reasonable and expected that:

(2) a resource that is not synchronized should not emit signals, whether it failed itself, a dependency failed, or it was excluded based on tags or schedules.

I think this also works.

As we move a bit more into signaling, I think it is reasonable and expected that:

(3) if a resource is scheduled to be refreshed, then the refresh happens immediately following its successful synchronization

It follows, however, that:

(4) a resource that is not synchronized cannot be refreshed, regardless of what resource notifies it or to what other resource it may be subscribed.

That stands to reason, but it seems not to be consistent with Puppet’s current behavior, at least under some circumstances. That’s the subject of this issue.

Now we come to a potential point of contention:

*should it be possible for resource A to be synchronized if it subscribes to or is notified by failed resource B, but has no non-signaling relationship with B? *

The current documentation suggests not, inasmuch as it describes subscribe and notify as augmented require and before, respectively.

I’m fine with that, but those constraints could be loosened to demand only an attempt at synchronization. That is, suppose Service[‘A’] subscribes to File[‘B’], but there are no other relationships between them.

Then certainly the agent must try to synchronize File[‘B’] before Service[‘A’], but if File[‘B’] fails then the agent could attempt to sync Service[‘A’] anyway (though it would not receive a signal from File[‘B’]).

In that case, the currently-documented behavior could still be achieved by naming File[‘B’] in both kinds of relationships (e.g. A could both require => File[‘B’] and subscribe => File[‘B’]). That would allow for gentler failure behavior in some cases, without precluding more stringent behavior where that is desired. There are therefore two possible rules here:

(5') No attempt is made to synchronize a resource if it has a signaling dependency on a resource that fails, or

(5") When one resource has a signaling dependency on another, any attempt to sync the dependency will be performed before any attempt to sync the dependent resource, but the latter attempt is not conditional on the success of the former.

Execs are a bit of a special case, though they might serve as a model for certain custom resources or perhaps future resource types. For them

(6) Execs should not be construed as having the same synchronization and refresh actions. Instead, they should be construed as having only one or the other.

Thus, when an Exec has refreshonly => true that should mean its command is a refresh action (and the sync action is equivalent to /bin/true), whereas when it has refreshonly => false, its command is the sync action. That will produce the same behavior as Exec current exhibits in the vast majority of cases — I think in all the cases that aren’t considered buggy.

There remains the question of what to do with dependencies on resources that sync successfully but fail to refresh. This is a second potential point of contention, but I suggest that

(7) When resource A has only a non-signaling dependency on resource B, then failure of resource B to refresh does not prevent resource A from being synchronized or refreshed.

The alternative, of course, is

(7') When resource A has any type of dependency on resource B, and resource B fails to refresh, then no attempt is made to sync resource A. (There’s no need to distinguish different types of dependencies in this case.)

If (7) is adopted, then that leaves the question of what to do when A has a signaling dependency on B, and B fails to refresh. I suggest that the rule should be the same as (7), but it would be possible to refuse to sync A in that case.

Wow, sorry for being long-winded (even for me). I hope this at least gets some meaningful discussion going on what the desired behavior is.

John Bollinger wrote:

Wow, sorry for being long-winded (even for me). I hope this at least gets some meaningful discussion going on what the desired behavior is.

That was great John. I did some minor reformatting to bold out the premises and points of contention.

re-reading.