Puppet users - Apr 2009 - puppetd no longer doingautomatic runs after updating to 0.24.8

Hi,

Last week we upgraded a bunch of our machines to 0.24.8, using the
1.el4.1 rpm from epel/redhat, and ever since then, it looks like
they''re no longer doing any runs on the half hour.  If we run manually
as a oneshot or a test via the init.d script, there''s no problems, but
there''s no activity on the logs of active runs.  I''ve tested
running
puppetd with --ignorecache, and also disabling and enableing --splay
(we keep it enabled normally) with no change, and in recent tests
dropped the runinterval to 60, but also with no difference.  Even with
debug, the client logs are quite simply blank and there''s no activity,
the debug logs on the puppetmaster only have some basic connections
upon first run.

Not sure if to take it to redhat or not, but there could be a
correlation between this feature and the fact these machines are on
RHEL4, we''ve got some RHEL5/centos 5 machines that seem to be ok.

Cant think of any other tests to try, as its in the internal
scheduling, not forcing a update/run, and ideas would be appreciated.

Thanks,

Daniel

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Apr 21, 2009, at 8:39 AM, Daniel Dekok wrote:
>
> Hi,
>
> Last week we upgraded a bunch of our machines to 0.24.8, using the
> 1.el4.1 rpm from epel/redhat, and ever since then, it looks like
> they''re no longer doing any runs on the half hour.  If we run
manually
> as a oneshot or a test via the init.d script, there''s no problems,
but
> there''s no activity on the logs of active runs.  I''ve
tested running
> puppetd with --ignorecache, and also disabling and enableing --splay
> (we keep it enabled normally) with no change, and in recent tests
> dropped the runinterval to 60, but also with no difference.  Even with
> debug, the client logs are quite simply blank and there''s no
activity,
> the debug logs on the puppetmaster only have some basic connections
> upon first run.
>
> Not sure if to take it to redhat or not, but there could be a
> correlation between this feature and the fact these machines are on
> RHEL4, we''ve got some RHEL5/centos 5 machines that seem to be ok.
>
> Cant think of any other tests to try, as its in the internal
> scheduling, not forcing a update/run, and ideas would be appreciated.
What happens if you run in debug mode with --no-daemonize?

I''ve not seen this, and I''d think you''d get at least
some kind of
message somewhere.

-- 
It is said that power corrupts, but actually it''s more true that power
attracts the corruptible. The sane are usually attracted by other things
than power. -- David Brin
---------------------------------------------------------------------
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On 21/04/2009, at 11:39 PM, Daniel Dekok wrote:
> Last week we upgraded a bunch of our machines to 0.24.8, using the
> 1.el4.1 rpm from epel/redhat, and ever since then, it looks like
> they''re no longer doing any runs on the half hour.
I think you are hitting the same Facter bug that I did with EL4.  
Essentially, Facter hangs trying to read /proc/uptime and /proc/ 
virtual (on my XenU guests). You should try the new Facter 1.5.5 RC1  
which has the fixes for these to see if that resolves the problem.

I actually had to manually fix all my servers because Puppet had  
stopped working. Also, when upgrading Facter, make sure you restart  
Puppet (if you''re running a daemon), otherwise you can also run into  
problems I''ve discovered.

cYa,
Avi

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Building a rpm of the facter 1.5.5rc1, using the EPEL 1.5.4 spec file
with a small mod or two (removing the permissions and not installing
the non existance COPYING file) and installing it fixes the problem in
my test environment as well, am going to fan it out today and confirm
its all good.

for the sake of completeness, running it in no deamonize mode doesn''t
change anything, after startup it just sits there.

On Apr 22, 7:38 am, Avi Miller <avi.mil...@gmail.com>
wrote:
> On 21/04/2009, at 11:39 PM, Daniel Dekok wrote:
>
> > Last week we upgraded a bunch of our machines to 0.24.8, using the
> > 1.el4.1 rpm from epel/redhat, and ever since then, it looks like
> > they''re no longer doing any runs on the half hour.
>
> I think you are hitting the same Facter bug that I did with EL4.  
> Essentially, Facter hangs trying to read /proc/uptime and /proc/
> virtual (on my XenU guests). You should try the new Facter 1.5.5 RC1  
> which has the fixes for these to see if that resolves the problem.
>
> I actually had to manually fix all my servers because Puppet had  
> stopped working. Also, when upgrading Facter, make sure you restart  
> Puppet (if you''re running a daemon), otherwise you can also run
into  
> problems I''ve discovered.
>
> cYa,
> Avi
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

FYI: I ran into this exact same issue today. I upgraded before
seeing/finding this thread. So it seems puppet for RHEL4 from EPEL is
currently broke until they update Facter.

On Tue, Apr 21, 2009 at 9:10 PM, Daniel Dekok <daniel.dekok@gmail.com>
wrote:
>
> Building a rpm of the facter 1.5.5rc1, using the EPEL 1.5.4 spec file
> with a small mod or two (removing the permissions and not installing
> the non existance COPYING file) and installing it fixes the problem in
> my test environment as well, am going to fan it out today and confirm
> its all good.
>
> for the sake of completeness, running it in no deamonize mode
doesn''t
> change anything, after startup it just sits there.
>
> On Apr 22, 7:38 am, Avi Miller <avi.mil...@gmail.com> wrote:
>> On 21/04/2009, at 11:39 PM, Daniel Dekok wrote:
>>
>> > Last week we upgraded a bunch of our machines to 0.24.8, using the
>> > 1.el4.1 rpm from epel/redhat, and ever since then, it looks like
>> > they''re no longer doing any runs on the half hour.
>>
>> I think you are hitting the same Facter bug that I did with EL4.
>> Essentially, Facter hangs trying to read /proc/uptime and /proc/
>> virtual (on my XenU guests). You should try the new Facter 1.5.5 RC1
>> which has the fixes for these to see if that resolves the problem.
>>
>> I actually had to manually fix all my servers because Puppet had
>> stopped working. Also, when upgrading Facter, make sure you restart
>> Puppet (if you''re running a daemon), otherwise you can also
run into
>> problems I''ve discovered.
>>
>> cYa,
>> Avi
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---