Here is my class
class puppetconf {
file { "/etc/puppet/puppetd.conf":
mode => 644,
owner => root,
group => root,
source => "puppet://puppet/cci/etc/puppet/puppetd.conf",
notify => exec[puppet_restart]
}
file { "/etc/init.d/puppet":
mode => 755,
owner => root,
group => root,
source => "puppet://puppet/cci/etc/init.d/puppet",
notify => exec[puppet_restart]
}
exec {"/etc/init.d/puppet restart":
refreshonly => true,
alias => puppet_restart
}
# service { puppet:
# ensure => running,
# }
}
Now this is working but it is spawning a extra puppetd process on all of
my clients and I am not sure why..
Jan 4 00:01:59 cc19-1 puppetd[12159]: Starting configuration run
Jan 4 00:01:59 cc19-1 puppetd[12159]: Finished configuration run in
0.73 seconds
Jan 4 00:02:00 cc19-1 puppetd[12355]: Starting configuration run
Jan 4 00:02:01 cc19-1 puppetd[12355]: Finished configuration run in
0.68 seconds
[root@cc19-1 ~]# ps -fe |grep puppet
root 12159 1 2 00:01 ? 00:00:01 /usr/bin/ruby
/usr/sbin/puppetd
root 12355 1 3 00:01 ? 00:00:01 /usr/bin/ruby
/usr/sbin/puppetd
Reason I have puppet managing puppet is so that if I need to change the
runinterval on every client I can have puppet manage it.
Any help would be greatly appreciated.
FYI, when I change the runinterval and puppet sees it the restart works
perfectly but it spawns an extra process.
Two things,
First when you change puppets config file it will notice and automatically
reload it''s configuration so a restart is not necessary.
Second, on redhat (possible other distros) the restart procedure uses a
function called "killproc", this function first looks for a pid file
in
/var/run/$base.pid and if this file does not exist uses the pidof with the
options "-o $$ -o $PPID -o %PPID", so when you call restart from
puppet if
there is no pid file the restart function does not see itself or the program
that executed it (puppetd) and will not kill the original instance. If you
really really want puppet to restart itself either make sure your pid file
is being created at /var/run/$base.pid or use the service type...
service{puppet:
hasrestart=>false
hasstatus=>false
pattern=>"puppetd"
stop=>"killall puppetd"
insure=>true
}
Second thought, looking at that I''m not even sure that is will succeed
in
the restart, it should succeed in killing puppetd though, you''ll have
to
experiment a little bit.
Thanks
Brian
On 1/3/08, Allen Sanabria <asanabria@linuxdynasty.org>
wrote:>
> Here is my class
> class puppetconf {
> file { "/etc/puppet/puppetd.conf":
> mode => 644,
> owner => root,
> group => root,
> source =>
"puppet://puppet/cci/etc/puppet/puppetd.conf",
> notify => exec[puppet_restart]
> }
> file { "/etc/init.d/puppet":
> mode => 755,
> owner => root,
> group => root,
> source => "puppet://puppet/cci/etc/init.d/puppet",
> notify => exec[puppet_restart]
> }
> exec {"/etc/init.d/puppet restart":
> refreshonly => true,
> alias => puppet_restart
> }
> # service { puppet:
> # ensure => running,
> # }
> }
>
>
>
> Now this is working but it is spawning a extra puppetd process on all of
> my clients and I am not sure why..
>
> Jan 4 00:01:59 cc19-1 puppetd[12159]: Starting configuration run
> Jan 4 00:01:59 cc19-1 puppetd[12159]: Finished configuration run in
> 0.73 seconds
> Jan 4 00:02:00 cc19-1 puppetd[12355]: Starting configuration run
> Jan 4 00:02:01 cc19-1 puppetd[12355]: Finished configuration run in
> 0.68 seconds
>
> [root@cc19-1 ~]# ps -fe |grep puppet
> root 12159 1 2 00:01 ? 00:00:01 /usr/bin/ruby
> /usr/sbin/puppetd
> root 12355 1 3 00:01 ? 00:00:01 /usr/bin/ruby
> /usr/sbin/puppetd
>
>
>
> Reason I have puppet managing puppet is so that if I need to change the
> runinterval on every client I can have puppet manage it.
>
> Any help would be greatly appreciated.
>
> FYI, when I change the runinterval and puppet sees it the restart works
> perfectly but it spawns an extra process.
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
Allen Sanabria wrote:> Here is my class > class puppetconf { > file { "/etc/puppet/puppetd.conf": > mode => 644, > owner => root, > group => root, > source => "puppet://puppet/cci/etc/puppet/puppetd.conf", > notify => exec[puppet_restart] > } > file { "/etc/init.d/puppet": > mode => 755, > owner => root, > group => root, > source => "puppet://puppet/cci/etc/init.d/puppet", > notify => exec[puppet_restart] > } > exec {"/etc/init.d/puppet restart": > refreshonly => true, > alias => puppet_restart > } > # service { puppet: > # ensure => running, > # } > } >What I use on Red Hat is this: class puppet-client { file { "/etc/puppet/puppet.conf": mode, source, etc. notify => Service["puppet"] } service { "puppet": ensure => running, enable => true, hasrestart => true } } And it seems to work fine for me. Kind regards, Jeroen van Meeuwen -kanarip
Thats interesting, I have personally witnessed, as have other, this effect with using the init script''s status command from puppet, in that situation puppet will try to start it''s self on every run because status does not look at it''s parent process. I have not directly experimented with puppet calling restart on it''s self, however I double checked and it results in the same call to pidof unless /var/run/puppetd.pid exist, even triple checked with set -x. One thing to note is that when a second puppetd starts up it should die immediately because it will try to bind to a socket that is already being used. A few questions... All of the scripts I''m looking at are on RHEL4, are you using a different version? Do you notice in your output from puppetd that puppet tries to start it''s self on every run? Can tell if puppet is actually restarting when it tries to? (pidof -x /usr/sbin/puppetd before and after) Does your /etc/init.d/puppet script call the status function for status and killproc for stop? (the default init script from the rpm does) Have you changed the status and killproc functions in /etc/init.d/functions, in particular the options to pidof? Do you have a /var/run/puppetd.pid file? (default scripts do not create a file at this location, they use /var/run/puppet/puppetd.pid) Sadly I do not currently have the opportunity of directly testing this situation with puppet so I can''t be 100% certain that I''m not missing something. In any case even if puppet does not correctly restart it will reload a changed config file by default so the desired results are still achieved and the side effects are, in most cases, an announce at worst. Thanks Brian On 1/4/08, Jeroen van Meeuwen <kanarip@kanarip.com> wrote:> > Allen Sanabria wrote: > > Here is my class > > class puppetconf { > > file { "/etc/puppet/puppetd.conf": > > mode => 644, > > owner => root, > > group => root, > > source => "puppet://puppet/cci/etc/puppet/puppetd.conf", > > notify => exec[puppet_restart] > > } > > file { "/etc/init.d/puppet": > > mode => 755, > > owner => root, > > group => root, > > source => "puppet://puppet/cci/etc/init.d/puppet", > > notify => exec[puppet_restart] > > } > > exec {"/etc/init.d/puppet restart": > > refreshonly => true, > > alias => puppet_restart > > } > > # service { puppet: > > # ensure => running, > > # } > > } > > > > What I use on Red Hat is this: > > class puppet-client { > file { "/etc/puppet/puppet.conf": > mode, source, etc. > notify => Service["puppet"] > } > > service { "puppet": > ensure => running, > enable => true, > hasrestart => true > } > } > > And it seems to work fine for me. > > Kind regards, > > Jeroen van Meeuwen > -kanarip > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Brian Finney wrote:> Thats interesting, > > I have personally witnessed, as have other, this effect with using the > init script''s status command from puppet, in that situation puppet will > try to start it''s self on every run because status does not look at it''s > parent process. I have not directly experimented with puppet calling > restart on it''s self, however I double checked and it results in the > same call to pidof unless /var/run/puppetd.pid exist, even triple > checked with set -x. One thing to note is that when a second puppetd > starts up it should die immediately because it will try to bind to a > socket that is already being used. > > A few questions... > > All of the scripts I''m looking at are on RHEL4, are you using a > different version?I''m using puppet on RHEL4, RHEL5, CentOS4, CentOS5, FC6, F7, F8 and rawhide. I''m not seeing puppet trying to restart itself unless I changed a file which needs the service to reload/restart itself. Note that I''m not manually triggering any /etc/init.d/puppet restart, and that I''m not using the Exec resource at all.> Do you notice in your output from puppetd that puppet tries to start > it''s self on every run?No, only when I change a file the service depends on or is notified of.> Can tell if puppet is actually restarting when it tries to? (pidof -x > /usr/sbin/puppetd before and after) > Does your /etc/init.d/puppet script call the status function for status > and killproc for stop? (the default init script from the rpm does) > Have you changed the status and killproc functions in > /etc/init.d/functions, in particular the options to pidof? > Do you have a /var/run/puppetd.pid file? (default scripts do not create > a file at this location, they use /var/run/puppet/puppetd.pid) >All I have is as much vanilla as possible. This in particular includes the init scripts. I do have a puppetd.pid in /var/run/puppet/puppetd.pid, it has something to do with permissions.> Sadly I do not currently have the opportunity of directly testing this > situation with puppet so I can''t be 100% certain that I''m not missing > something. > > In any case even if puppet does not correctly restart it will reload a > changed config file by default so the desired results are still achieved > and the side effects are, in most cases, an announce at worst. >Gheghe, I noticed this. When you start puppet for the first couple of times, once it pulls in the /etc/puppet/puppet.conf file (which in my case says to not use any colors), it applies it immediately (e.g. during the same run). Kind regards, Jeroen van Meeuwen -kanarip