Puppet users - Aug 2008 - using running - should it always restart?

Hi,

I am fairly new to using puppet, but have it setup on 25 machines.
Just doing some basic configuration management. Recently I decided to
try working with updating some services config files and used the
ensure => running tags. My question is simple - if the source file
does NOT change and I use a subscribe, why does the system keep
restarting the daemon every time puppet runs?

A simple example is setting some config file changes for netbackup. Of
course it worked the first time and the config file was updated and
netbackup was reloaded. But I have not made any changes to the config
and puppet says it does not see any and yet every 30 minutes it
restarts netbackup.

Should I expect this behavior if I am not using any customized "check
status" scripts?

thanks
~J~
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On 8/4/2008 1:02 PM, Jewels wrote:
> Should I expect this behavior if I am not using any customized "check
> status" scripts?
http://reductivelabs.com/trac/puppet/wiki/TypeReference#service has two 
relevant points:

The hasstatus parameter is useful to specify if the service init file 
(or equivalent) can return a status. Most don''t. Also, by default, the 
process table is searched for the service name if the hasstatus 
parameter is absent.

The pattern parameter is used on systems that don''t have init scripts, 
and is *also* used to override the default search for the service name 
for status checks. "If this is left unspecified and is needed to check 
the status of a service, then the service name will be used instead."

So these two features (and the fact that service names rarely match the 
daemons they run) conspire to make you include lots of pattern 
parameters on your service definitions. I do the following for samba and 
winbind:

     service {
         "samba":
             pattern   => "/usr/sbin/smbd",
             ensure    => running,
             subscribe => File["/etc/samba/smb.conf"];
         "winbind":
             pattern   => "/usr/sbin/winbindd",
             ensure    => running,
             subscribe => File["/etc/samba/smb.conf"];
     }

-- 
Mike Renfro  / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, Aug 4, 2008 at 11:32 AM, Mike Renfro <renfro@tntech.edu>
wrote:
> So these two features (and the fact that service names rarely match the
> daemons they run) conspire to make you include lots of pattern
> parameters on your service definitions. I do the following for samba and
> winbind:
>
>     service {
>         "samba":
>             pattern   => "/usr/sbin/smbd",
>             ensure    => running,
>             subscribe => File["/etc/samba/smb.conf"];
>         "winbind":
>             pattern   => "/usr/sbin/winbindd",
>             ensure    => running,
>             subscribe => File["/etc/samba/smb.conf"];
>     }
We do much the same, as well as fixing the init scripts so they have a
''status'' and pushing our upstream folks to integrate that
patch. Our
hope is that someday the upstream guys will ''do it right'' and
we can
get rid of those ''pattern'' statements :-)

--Paul

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

The "hasstatus" option seemed to have fix it. I could have used the
pattern too, but with the way netbackup has a million daemons
associated with it - it was easier with status.

thanks so much...


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Wed, Aug 6, 2008 at 12:32 PM, Jewels <IslandJewel@gmail.com>
wrote:
>
> The "hasstatus" option seemed to have fix it. I could have used
the
> pattern too, but with the way netbackup has a million daemons
> associated with it - it was easier with status.
>
> thanks so much...
I am having s imiliar issue on my centos boxes with the service type.
some but not all the service seem to react correctly with the
hasstatus => true and some appear to ignore it. SSH works fine, but
puppetd,xinetd,irda, bluetooth do not.

I have noticed one common factor in the service that do work and the
ones that do not work with the hasstatus setting. All teh ones that
work report with same application name as the service name:

# service sshd status
sshd (pid 4928) is running...

And the ones that do not have a different application name:

# service puppet status
puppetd (pid 18543) is running...

Has any one else dealt with this? Should I enter it a bug report?

Evan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Evan Hisey wrote:
> On Wed, Aug 6, 2008 at 12:32 PM, Jewels <IslandJewel@gmail.com>
wrote:
>> The "hasstatus" option seemed to have fix it. I could have
used the
>> pattern too, but with the way netbackup has a million daemons
>> associated with it - it was easier with status.
>>
>> thanks so much...
> 
> I am having s imiliar issue on my centos boxes with the service type.
> some but not all the service seem to react correctly with the
> hasstatus => true and some appear to ignore it. SSH works fine, but
> puppetd,xinetd,irda, bluetooth do not.
> 
> I have noticed one common factor in the service that do work and the
> ones that do not work with the hasstatus setting. All teh ones that
> work report with same application name as the service name:
> 
> # service sshd status
> sshd (pid 4928) is running...
> 
> And the ones that do not have a different application name:
> 
> # service puppet status
> puppetd (pid 18543) is running...
The hasstatus option doesn''t actually use the output string, just the
return
code from the script.
> Has any one else dealt with this? Should I enter it a bug report?
You should definitely file a bug report, assuming one hasn''t already. 
In
Fedora at least, RedHat has been making an effort lately to ensure that all of 
the scripts are LSB compliant in their return codes.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
     GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---