On Thu, Mar 12, 2015 at 4:21 AM, James Green <james.mk.gr...@gmail.com> wrote:
> I was running puppet agent -t --noop repeatedly with this error. > > Running again, this time omitting --noop, it succeeded. Not entirely clear > what this tells me... > > On 12 March 2015 at 10:58, James Green <james.mk.gr...@gmail.com> wrote: > >> Error: >> /Stage[main]/Our_unattended_upgrades/File[/etc/apt/apt.conf.d/20auto-upgrades]: >> Could not evaluate: Could not retrieve file metadata for >> puppet:///modules/our_unattended_upgrades/etc/apt/apt.conf.d/20auto-upgrades: >> end of file reached >> Wrapped exception: >> end of file reached >> >> Versions on the server: >> >> ii facter 2.4.1-1puppetlabs1 all >> Ruby module for collecting simple facts about a host operating >> system >> ii hiera 1.3.4-1puppetlabs1 all >> A simple pluggable Hierarchical Database. >> ii puppet 3.7.4-1puppetlabs1 all >> Centralized configuration management - agent startup and >> compatibility scripts >> ii puppet-common 3.7.4-1puppetlabs1 all >> Centralized configuration management >> ii puppetdb 2.2.2-1puppetlabs1 all >> PuppetDB Centralized Storage. >> ii puppetdb-terminus 2.2.2-1puppetlabs1 all >> Connect Puppet to PuppetDB by setting up a terminus for PuppetDB. >> ii puppetlabs-release 1.0-11 all >> "Package to install Puppet Labs gpg key and apt repo" >> ii puppetmaster-common 3.7.4-1puppetlabs1 all >> Puppet master common scripts >> ii puppetmaster-passenger 3.7.4-1puppetlabs1 all >> Centralised configuration management - master setup to run under >> mod passenger >> >> Are we looking at a known bug or are we really going to need to debug >> this? >> >> James >> >> >> On 11 March 2015 at 09:47, James Green <james.mk.gr...@gmail.com> wrote: >> >>> Hi, >>> >>> Sorry for the delayed response. >>> >>> In our case we are using Passenger. >>> >>> On 5 March 2015 at 15:24, Henrik Lindberg < >>> henrik.lindb...@cloudsmith.com> wrote: >>> >>>> On 2015-05-03 12:02, James Green wrote: >>>> >>>>> We occasionally have an agent fail because of this. I'm told by others >>>>> running the agents more frequently that it appears to be at random and >>>>> not on anything particularly large. >>>>> >>>>> >>>> If you are using webrick then it is most likely a concurrency problem >>>> (more than one agent calling in at the same time). Webrick is not >>>> recommended for production use because of this. >>>> >>>> - henrik >>>> -- >>>> >>>> Visit my Blog "Puppet on the Edge" >>>> http://puppet-on-the-edge.blogspot.se/ >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Puppet Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to puppet-users+unsubscr...@googlegroups.com. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/puppet-users/md9sfc%24r1e%241%40ger.gmane.org. >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAMH6%2Bay6EoB1zCZ587s%2B-gWno%3DGdHBR%3DKkhmD1aVHHXn66TsVw%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-users/CAMH6%2Bay6EoB1zCZ587s%2B-gWno%3DGdHBR%3DKkhmD1aVHHXn66TsVw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > The fact that you are on puppet 3.7 and the error occasionally occurs, but not always, makes me think it's https://tickets.puppetlabs.com/browse/PUP-3238. Starting in puppet 3.7, we've added support for persistent HTTP connections, see https://docs.puppetlabs.com/puppet/latest/reference/subsystem_agent_master_comm.html#persistent-connections--keepalive . This eliminates the TCP/SSL handshake for every file metadata and content request, and greatly reduces the load on the master. But there is a possibility that a loadbalancer or puppetmaster may close an idle connection. Unfortunately, ruby does not surface socket errors when writing a request, only when reading. So often this issue manifests itself with "end of file" reached. To confirm if this is the case, make sure the puppet agent's http_keep_alive setting is less than the keep alive on your master. See https://docs.puppetlabs.com/references/3.7.latest/configuration.html#httpkeepalivetimeout. You can also disable keepalive on the client by setting the timeout to 0. Most likely your catalog is performing a long'ish operation, e.g. installing a package, the master closes the idle connection, the agent then tries to retrieve a file whose source is a puppet URI, which triggers a metadata request, and the agent receives the EOF exception. Josh -- Josh Cooper Developer, Puppet Labs *PuppetConf 2015 <http://2015.puppetconf.com/> is coming to Portland, Oregon! Join us October 5-9.* *Register now to take advantage of the Early Adopter discount <https://www.eventbrite.com/e/puppetconf-2015-october-5-9-tickets-13115894995?discount=EarlyAdopter> * *—**save $349!* -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2Bu97ukpopZZOcHp1bB5V_Ae34o_%3Dn5vcTakBx3rFccWO5trbg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
