Hi,
running a puppet master managing 15-20 agents. When I start the
puppetmaster service system load will stay around 2 for a couple of minutes
(sometimes hours). Then after a while (sometimes sooner, sometimes later)
system load increases and puppetmaster process keeps spawning child
processes
> rpm -qa | egrep "puppet|ruby"
rubygem-rake-0.8.7-2.1.el6.noarch
ruby-mysql-2.8.2-1.el6.x86_64
libselinux-ruby-2.0.94-5.3.el6.x86_64
puppet-3.0.2-1.el6.noarch
puppet-dashboard-1.2.16-1.el6.noarch
ruby-1.8.7.352-7.el6_2.x86_64
ruby-irb-1.8.7.352-7.el6_2.x86_64
rubygems-1.3.7-1.el6.noarch
ruby-augea
When having more than one process...
> ps faux | grep "puppet master" | grep -v grep
puppet5100 92.0 2.7 427180 329728 ? Rsl 09:22 119:27
/usr/bin/ruby /usr/bin/puppet master
puppet 11957 99.9 1.6 300168 200224 ? R10:07 83:53 \_
/usr/bin/ruby /usr/bin/puppet master
> ... strace-ing child process shows nothing...
>
> strace -v -p 11957
> Process 11957 attached - interrupt to quit
>
>
> Will watch this for some time now - but so far (~30 minutes) didn't see
> anything going on.
>
> Any other idea about how to find out what process 11957 actually is
doing?
Am Donnerstag, 3. Januar 2013 11:41:21 UTC+1 schrieb R.I. Pienaar:
>
>
>
> - Original Message -
> > From: al...@gmx.de
> > To: puppet...@googlegroups.com
> > Sent: Thursday, January 3, 2013 10:36:35 AM
> > Subject: [Puppet Users] Re: puppet master keeps spawning new child
> process
After monitoring the "Father" process a bit more I realized that it often
happens that new processes are created - usually they don't live long.
> strace -f -v -p 5100 -o /tmp/strace.5100.log
Process 5100 attached with 2 threads - interrupt to quit
Process 18702 detached
Process 19996 attached
Pr
Seeing this a lot lately, restarting puppet master service usually resolves
it:
Jan 3 13:17:01 puppet-master[24120]: (///Puppet) Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed when searching for node : Failed to find via exec: Execution of
'/usr/share/puppet-dashb
> There's another flag to strace, -f, if I recall correctly, that will
> follow forks of children.
>
straced father process (pid 14850) using -f, caught the moment when a
process was spawned that didn't go away and stayed at 100% cpu load (pid
18915). It's a lot output so I grep'ed for child
Disabling puppet dashboard helped - 12 hours without any "frozen" 100%
child process. Now investigating if it's dashboard's external node command.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
http
Am Freitag, 4. Januar 2013 13:17:46 UTC+1 schrieb al...@gmx.de:
> Disabling puppet dashboard helped - 12 hours without any "frozen" 100%
> child process. Now investigating if it's dashboard's external node command.
Commenting out ENC-related lines in puppet.conf fixed this. Calling the
externa
>
> On Thursday, January 3, 2013 6:30:33 AM UTC-6, al...@gmx.de wrote:
>>
>> Seeing this a lot lately, restarting puppet master service usually
>> resolves it:
>>
>> Jan 3 13:17:01 puppet-master[24120]: (//> agent>/Puppet) Could not retrieve catalog from remote server: Error 400 on
>> SERVER:
Hi,
my problem: puppet-dashboard doesn't seem to care about the *
no_longer_reporting_cutoff* value. Was set to 3600 and just did set it to
600 but a node who sent his last report (last run failed... maybe that's
important?) over 5 hours ago is still not marked as "Has not reported" yet.
Thing i
Am Dienstag, 22. Januar 2013 17:11:18 UTC+1 schrieb jcbollinger:
>
> First guess: you're expressing the cutoff value in seconds, but the back
> end is interpreting it as minutes.
>
> Was my first guess too, but (value still set 600 whatevers) my dashboard
still shows the mentioned machine as "fa
13 matches
Mail list logo
