On 5 July 2011 14:24, Martin Alfke <tux...@gmail.com> 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). >
Yeah, so the stop will try a bunch of ways to find the process, and if the pid file doesn't exist then it just uses pidof. Hmm, not great. So I can see how this happens IF the stop is executed, however there still seems to be no reason to get there in the first place. That said if I try to run a stop during a run it doesn't work. I've cleared the issue as described, and I wouldn't expect that what I did (commenting out the ensure / enable) would actually do anything like clearing any old pid files or anything... And it's by no means prevalent on any of the rhel5 systems we have. Thanks Chris -- 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.
