# LWRPs always reporting as updated

**URL:** <https://discourse.chef.io/t/lwrps-always-reporting-as-updated/2911>\
**Category:** Chef Infra (archive)\
**Created:** [June 9, 2012, 8:08pm UTC](https://discourse.chef.io/t/lwrps-always-reporting-as-updated/2911 "2012-06-09T20:08:52Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_E\_Vincent\_lusis](https://avatars.discourse-cdn.com/v4/letter/j/c89c15/32.png) [@John\_E\_Vincent\_lusis](https://discourse.chef.io/u/John_E_Vincent_lusis)\
**Post date:** [June 9, 2012, 8:08pm UTC](https://discourse.chef.io/t/lwrps-always-reporting-as-updated/2911/1 "2012-06-09T20:08:52Z")

</div>

Hey all,

In the process of migrating to continuous run of the chef-client on a  
few servers, we started shipping resource change counts over to  
graphite. The idea was that we would get an alert if something changed  
(temporary solution) as well as tracking drift over time.

What I discovered is that a few LWRPs are causing runs to always show  
updated resources even though they "technically" didn't change  
anything. Before I work on pull requests (because this most def is  
unexpected behavior to me), I'd like to get some ideas on possible  
fixes.

1. nagios\_nrpecheck resource  
My best guess here is that the move from a template to a file resource  
with content attribute is the cause here:

> <https://github.com/sous-chefs/nagios/commit/e9b117f179c30472e181032d4f8ac7f93cf3c404>

I haven't dug too deeply but I'm guessing that the file resource's  
handling of contents is the issue here. My thought is that, for cases  
where content is being written to the file directly by the resource,  
would it not make sense to build the file in the cache path first,  
checksum against destination (if it exists) and then move the file in  
place at the end (as opposed to writing contents in place? It appears  
that in-place is what's happening now via my first glance at the code.

1. chef\_handler resourse  
This one is new territory to me having not used them before now. I  
read over the comments here:

[https://github.com/opscode-cookbooks/chef\_handler/blob/master/providers/default.rb#L35-43](https://github.com/opscode-cookbooks/chef_handler/blob/master/providers/default.rb#L35-43)

Is a guard of some kind enough here to short-circuit  
updated\_by\_last\_action? Again, I'm willing to dig in but I never run  
in daemon mode. I'm not sure of the state of the exception\_ and  
report\_ handlers at that point. The explict delete\_if + push leads me  
to believe that it HAS to be run everytime right now.

What's the source of the issue here and maybe I can tackle it? Is  
there any way of knowing if chef-client is running daemonized or not?

Let me know and thoughts you all have.

Thanks!  
John E. Vincent (@lusis)

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [June 11, 2012, 3:49pm UTC](https://discourse.chef.io/t/lwrps-always-reporting-as-updated/2911/2 "2012-06-11T15:49:58Z")

</div>

On Saturday, June 9, 2012 at 1:08 PM, John E. Vincent (lusis) wrote:

> Hey all,
> 
> In the process of migrating to continuous run of the chef-client on a  
> few servers, we started shipping resource change counts over to  
> graphite. The idea was that we would get an alert if something changed  
> (temporary solution) as well as tracking drift over time.
> 
> What I discovered is that a few LWRPs are causing runs to always show  
> updated resources even though they "technically" didn't change  
> anything. Before I work on pull requests (because this most def is  
> unexpected behavior to me), I'd like to get some ideas on possible  
> fixes.
> 
> 1. nagios\_nrpecheck resource  
> My best guess here is that the move from a template to a file resource  
> with content attribute is the cause here:
> 
> [Updating nrpe LWRP so that it no longer uses a template to write out … · sous-chefs/nagios@e9b117f · GitHub](https://github.com/opscode-cookbooks/nagios/commit/e9b117f179c30472e181032d4f8ac7f93cf3c404)
> 
> I haven't dug too deeply but I'm guessing that the file resource's  
> handling of contents is the issue here. My thought is that, for cases  
> where content is being written to the file directly by the resource,  
> would it not make sense to build the file in the cache path first,  
> checksum against destination (if it exists) and then move the file in  
> place at the end (as opposed to writing contents in place? It appears  
> that in-place is what's happening now via my first glance at the code.

The file resource checksums the in-memory `content` field and compares to the on-disk version, so it's idempotent. This behavior is different than cookbook\_file and template, which has some interesting implications for SE Linux and Windows, but shouldn't affect notifications.

There was a bug with all file-based resources sometimes _not_ triggering notifications in Chef 0.10.10, but that's fixed in the 10.12 RC. And if you find that using the file resource as designed is causing it to trigger notifications incorrectly, that would of course be a bug, too.

> 1. chef\_handler resourse  
> This one is new territory to me having not used them before now. I  
> read over the comments here:
> 
> [https://github.com/opscode-cookbooks/chef\_handler/blob/master/providers/default.rb#L35-43](https://github.com/opscode-cookbooks/chef_handler/blob/master/providers/default.rb#L35-43)
> 
> Is a guard of some kind enough here to short-circuit  
> updated\_by\_last\_action? Again, I'm willing to dig in but I never run  
> in daemon mode. I'm not sure of the state of the exception\_ and  
> report\_ handlers at that point. The explict delete\_if + push leads me  
> to believe that it HAS to be run everytime right now.

What that code is doing is implementing code reloading similar to what Rails' dev mode would do. I haven't used the cookbook personally, but you could imagine that this action could get triggered by a notification from a cookbook\_file, in which case you'd only reload when the code changes. I'm not sure what that implies as far as using the handler cookbook.

> What's the source of the issue here and maybe I can tackle it? Is  
> there any way of knowing if chef-client is running daemonized or not?
> 
> Let me know and thoughts you all have.
> 
> Thanks!  
> John E. Vincent (@lusis)

--  
Dan DeLeo