So when puppetd crashes/whatever, and a pid file is left behind, SMF in Solaris will try restarting puppet, but fail. And then it sits there restarting it forever. I''m not sure if I can adjust the flap detection in SMF.. it isn''t disabling the service for "restarting too quickly" because it takes so long to start. Probably because I''m NFS-mounting ruby. The result is that after an NFS server downtime, puppetd on ~100 boxes is no longer running. Would it make sense for puppet to check the existence of a pid file, *and* check the process list before refusing to start? Facter provides the correct ''ps'' per-platform, so this should work. If a puppetd process isn''t actually running, it should remove the pid file and then successfully daemonize, IMHO :) -Charlie
On Sat, Dec 30, 2006 at 12:04:51PM -0800, Charlie Schluting wrote:> If a puppetd process isn''t actually running, it should remove the pid > file and then successfully daemonize, IMHO :)Yep, it should. I added this to puppetmasterd a while ago, but never got around to retrofitting it to puppetd. Just so you know that *somebody* else cares about it... <grin> - Matt -- It has become trendy, in some circles, to lament the Internet''s poor performance/congestion/[...]/<insert issue here>. After firmly denouncing the Internet, the company or individual then touts their product, which will fix/replace/augment the Internet. -- Daniel Golding, NANOG
On Dec 30, 2006, at 3:50 PM, Matthew Palmer wrote:> > Yep, it should. I added this to puppetmasterd a while ago, but > never got > around to retrofitting it to puppetd. Just so you know that > *somebody* else > cares about it... <grin>Hmm. I actually added this ability to client locking in client/ master.rb, but apparently didn''t make it a generic feature. Matt, where did you add this functionality to puppetmasterd? I don''t see it. -- I don''t always know what I''m talking about, but I''m always pretty much convinced that I''m right. -- musician Mojo Nixon --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Sat, Dec 30, 2006 at 05:21:05PM -0600, Luke Kanies wrote:> On Dec 30, 2006, at 3:50 PM, Matthew Palmer wrote: > > > > Yep, it should. I added this to puppetmasterd a while ago, but > > never got > > around to retrofitting it to puppetd. Just so you know that > > *somebody* else > > cares about it... <grin> > > Hmm. I actually added this ability to client locking in client/ > master.rb, but apparently didn''t make it a generic feature. > > Matt, where did you add this functionality to puppetmasterd? I don''t > see it.My recollection appears to be faulty, and it was puppetd (according to #290) that I fixed this for -- which I recall now, because it was the run lock file, not the actual PID file, that I fixed up. The patch was in #190. The design I''ve come up with is for a generic pidlock class, which will do the job for all daemons and also the run lock file. Now I''ve got to code it and commit it. It''s going to be pretty generic, as I have need of similar functionality for another project I''m working on. - Matt -- Just because we work at a University doesn''t mean we''re surrounded by smart people. -- Brian Kantor, in the monastery
On Sun, Dec 31, 2006 at 11:06:27AM +1100, Matthew Palmer wrote:> My recollection appears to be faulty, and it was puppetd (according to #290)According to #299, actually. Whoops. - Matt -- I still can''t see a wasp without thinking "400K 1W" -- Derek Potter, uk.misc
On 12/30/06, Matthew Palmer <mpalmer@hezmatt.org> wrote:> According to #299, actually. Whoops.Awesome, thanks :) -Charlie
On Sun, Dec 31, 2006 at 05:32:20PM -0800, Charlie Schluting wrote:> On 12/30/06, Matthew Palmer <mpalmer@hezmatt.org> wrote: > > According to #299, actually. Whoops. > > Awesome, thanks :)And if you follow puppet-commits, you will notice that I''ve gone through and fixed up all the PID file handling code, so they should all work as $DEITY intended. It''d be handy if you could test it all thoroughly, to make sure there''s no unpleasantness hiding behind the scenes. - Matt -- when SuSE are doing better than you at publishing the tools they use, it''s a hint that maybe you suck. -- Andrew Suffield, debian-devel
On Dec 31, 2006, at 11:45 PM, Matthew Palmer wrote:> > And if you follow puppet-commits, you will notice that I''ve gone > through and > fixed up all the PID file handling code, so they should all work as > $DEITY > intended. It''d be handy if you could test it all thoroughly, to > make sure > there''s no unpleasantness hiding behind the scenes.And I''m very happy you''ve got that done. I think Puppet is almost ready for the next release, so it should be this week. -- As a general rule, don''t solve puzzles that open portals to Hell. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
I just wanted to say thanks, this is working well in 0.22.0. At first I had an issue with FIle.unlink() not working, but that seems to have been a strange isolated incident. It has tested fine everywhere else, and now I''ve pushed my puppet deployment to most all of my machines. Thanks :) Now to write some providers.. I''ll get back to you (the list) with questions on that one. -Charlie
On Jan 9, 2007, at 11:25 AM, Charlie Schluting wrote:> I just wanted to say thanks, this is working well in 0.22.0.Great, glad to hear that Matt''s work has fixed the PID problems.> At first I had an issue with FIle.unlink() not working, but that seems > to have been a strange isolated incident. It has tested fine > everywhere else, and now I''ve pushed my puppet deployment to most all > of my machines. Thanks :)Sweet.> Now to write some providers.. I''ll get back to you (the list) with > questions on that one.Heh, we''re all eyes. :) -- Always read stuff that will make you look good if you die in the middle of it. -- P. J. O''Rourke --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com