On 07/05/2011 09:24 AM, Martin Alfke wrote:
On 07/05/2011 03:19 PM, Brian Gallew wrote:
> I was seeing the behavior on my Solaris boxes when running Puppet under
> SMF. The issue, in my case, was that I was trying to work around an SMF
> bug. My "workaround" was to "svcadm disable puppetd;svccfg import
> /var/svc/manifest/network/puppetd.xml;svcadm enable puppet". The astute
> viewer will notice that "svcadm disable puppetd" will cause SMF to send
> SIGTERM to puppet, at which point it will stop (as instructed) the
> current run, so the new manifest will not be imported and the service
> will not be re-started. It was all very amusing, except for the bit
> where I had to fix a bunch of systems that weren't running Puppet
> anymore. Mea culpa.
I have seen a similar behavior on RHEL5.
/sbin/service puppet status gets information on actual running puppet run.
We fixed the puppet init script to verify whether the running puppet
process has parent pid 1 (init).
The key to that sort of thing is to make sure
the process that you launch has a life of its own.
So, instead of essentially
system ("
svcadm disable puppetd; \
svccfg import /var/svc/manifest/network/puppetd.xml; \
svcadm enable puppet \
" )
add an extra set of parenthesis and put the script in
the background:
system ("
( sleep 1; svcadm disable puppetd; \
svccfg import /var/svc/manifest/network/puppetd.xml; \
svcadm enable puppet ) & \
" )
The sleep is there because, on linux at least, the child will
run first otherwise. Well, that's the basic idea. It's been
a while since I had to do anything like that.
--
vagn
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
