I ran into the same issue this weekend, and discovered that the Amazon yum
repo's latest Puppet package (2.7.25) has ruby1.8 "shebang'd". With that
puppet release, you can have ruby2.0 on the system as the default and still
have puppet running correctly. If your hosts are running the puppet ag
Update on this -- Amazon rev'd Yum to v3.4.3-137 at the same time -- most
likely the source of the issue... but it's still causing me problems.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving em
In my Amazon Linux environment, I have a couple of images on which I've
changed the default python installation from 2.6 to 2.7. These hosts have
been running fine for a couple of months, but in the past couple of days
I've discovered they've developed an error when running Puppet catalogs.
T
In resolving bug 15980, the pip package provider was changed to recognize
the RedHat osfamily fact and use the executable name "pip-python" in those
environments. This does not take into account environments where pip has
been installed via easy_install or by custom rpm providers. In those
en
oper wrote:
>
> Hi Michael,
>
> On Thu, Jun 6, 2013 at 8:01 AM, Michael O'Dea
> > wrote:
>
>> I neglected to mention this crash leaves behind the lockfile, so while
>> the puppet service is still running, all future puppet runs exit saying
>> "another
I neglected to mention this crash leaves behind the lockfile, so while the
puppet service is still running, all future puppet runs exit saying
"another puppet run is in progress".
On Thursday, June 6, 2013 10:55:21 AM UTC-4, Michael O'Dea wrote:
>
> I noticed that a numbe
I noticed that a number of my Windows hosts had stopped dialing in, and
upon closer inspection I found that Puppet was crashing in Ruby and
wevtapi.dll. I can't find any reference to this in the issue tracker,
although I've got over a dozen occurrences in my environment, all with the
same desc
Oops nevermind. The host I sampled in the logs still was running the
2.7.18 Puppet client. I re-checked a host running 3.1.1 and it does appear
to be varying it's runs somewhat. Need to retire all those puppet 2.7
hosts!
On Friday, May 24, 2013 9:47:49 AM UTC-4, Michael O'Dea wr
I have a substantial number of Windows hosts running puppet 3.1.1 with the
following in their puppet.conf:
runinterval = 1800
> splay = true
> splaylimit = 900
However in checking puppet logs, I'm finding that these hosts are dialing
in at 30 minute intervals +/- 5-10 seconds. Can someone pro
I see this error all the time when I forget to sudo a puppet run. My only
guess is that puppet agent is being run twice, once as root and once as
ubuntu, and you're seeing the results of the second run. I'm not familiar
with the node_aws stuff however, I've worked up userdata profiles to do th
ivating.
On Thursday, April 4, 2013 3:19:00 PM UTC-4, Michael O'Dea wrote:
>
> Hi all,
>
> I recently started using the Nagios resources to populate a monitoring
> server. I cycle hosts fairly quickly in my environment so already I've had
> five hosts come and go
Hi all,
I recently started using the Nagios resources to populate a monitoring
server. I cycle hosts fairly quickly in my environment so already I've had
five hosts come and go from under Nagios. After a fair amount of searching
I discovered "puppet node deactivate" and performed same on the
M
On Tuesday, February 12, 2013 1:22:33 PM UTC-5, Michael O'Dea wrote:
>
> Hopefully not thread hijacking, hope my issue is the same. Strangely, I
> had this problem last week and then resolved it when I made a few more
> changes to the MSI. The issue has just now returned for me,
Hopefully not thread hijacking, hope my issue is the same. Strangely, I
had this problem last week and then resolved it when I made a few more
changes to the MSI. The issue has just now returned for me, and I'm not
clear how my latest changes (from a debug mode package to a release
package) w
14 matches
Mail list logo
