Luke, I was the guy who brought up puppet client fails last June at the SF meetup.
The memory footprint of the puppetd client in idle mode (between triggers) was enough of a reason to dump the always-on client, but I also found that they crashed regularly whenever there was any difficulty contacting the puppet master. (too many concurrent, etc) I just run my clients in cron like this: /usr/bin/perl -e "sleep int(rand(60*30));" ; /usr/sbin/puppetd --test 1> /tmp/puppetd.log I would be more than happy to help debug why the client crashes. What do you suggest I run it with? Is there a ruby debugger? Unfortunately I'll probably not want to upgrade to the newest puppet for this test harness, but I'd be happy to put 0.24.4 up for some crash and burns. --joel On Tue, Apr 21, 2009 at 12:04 PM, Luke Kanies <l...@madstop.com> wrote: > > On Apr 21, 2009, at 2:19 AM, Jean-Baptiste Quenot wrote: > >> >> 2009/4/6 Mike Renfro <ren...@tntech.edu>: >> >>> I'd normally expect that to work, but I just have puppet keep cron >>> running, and have a periodic cron job that checks if puppet has died, >>> and if so, restarts it: >> >> Interesting, but why would you expect Puppet to die? Would you expect >> Apache, Nginx or worse MySQL to die randomly like this? >> >> I'm a Puppet user since nearly two years now, and in the big picture >> of my web servers I find that puppetd is not the most reliable piece >> of software. It dies every day, and my colleagues complain about this >> regularly because their installed packages are not uptodate as they >> expect. So I have to start it again and again on all machines. Is >> Puppetd dying because of network problems? I believe so, but I think >> it should be fixed instead of finding creative ways to keep puppetd >> running, especially since I request it to run every 5 minutes as a >> daemon. > > I agree, these problems shouldn't exist, and when they do they should > be fixed. > > The problem is that we can't seem to find anyone who has the time or > interest in debugging the problem, and we not-too-surprisingly can't > reproduce it ourselves. Everyone who has the problem just shrugs and > switches to cron, and pretty much stops responding to our emails > asking for help fixing the problem. > > What we really need is someone who's having these problems and is > willing to spend some time investigating. I expect it's not that > complicated, it just needs to be hunted down. > > And, for the record, I think this got a lot better in 0.24.8 (or maybe > 0.24.7?). We found a few cases where errors could propagate far > enough to kill the client, and I think we've eradicated nearly all of > them. > >> Is anyone using puppetd in a WAN setup with default Webrick server >> successfully? Shall I switch the HTTP server to Mongrel to gain >> reliability? I'll test this setup. But if puppetd fails on the >> client side, I'm not certain that changing the server's HTTP server >> would actually prevent the client to fail at all... > > We need to add logs or something to clarify this, but you should > *definitely* switch away from Webrick if you're having any kind of > performance or reliability problems. Or if you're not. > > -- > Death and taxes are inevitable; at least death doesn't get worse every > year. > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
