Issue #4517 has been updated by Rein Henrichs.
Naresh, so far we've been unable to reproduce the CLOSE_WAIT issue. In addition to which server your puppet master is using, it would be useful to be able to read your puppet master's log when run with --verbose and --debug options. You can send them to me at [email protected]. Any other information about the tcp traffic that you have access to (size of the catalogs being sent back to the agent, etc) would be useful as well. ---------------------------------------- Bug #4517: async_storeconfigs + activemq queueing support causes puppetmaster to keep connections with clients in CLOSE_WAIT state http://projects.puppetlabs.com/issues/4517 Author: Naresh V. Status: Needs more information Priority: Normal Assignee: Rein Henrichs Category: stored configuration Target version: queued Affected version: 2.6.1rc1 Keywords: stored configuration, async_storeconfigs, queueing, ActiveMQ Branch: Hi, We recently upgraded our puppetmaster to CentOS 5.5 (from RHEL4) and installed puppet via gems on a ruby-enterprise installation. (plan was to use passenger). So my initial setup consisted of: 1. CentOS 5.5 2. ruby-enterprise-1.8.7-2010.02 3. gem install puppet pg (dependencies too, from gem; pg is for postgresql for stored configs) I followed http://projects.puppetlabs.com/projects/puppet/wiki/Using_Stored_Configuration to enable/configure ActiveMQ as an external message bus. (ActiveMQ had its default configuration) puppet.conf: <pre> [main] ... queue_type = stomp queue_source = stomp://localhost:61613 dbadaptor = postgresql dbserver = localhost dbuser = puppet dbname = puppet [master] factsync = true async_storeconfigs = true thin_storeconfigs = true dbadapter = postgresql dbserver = localhost dbuser = puppet dbname = puppet dbconnections = 100 environments = staging,production report = true </pre> netsat: <pre> netstat -tpv | grep :8140 tcp 38 0 puppet:8140 inbound-us2.mailhostb:55260 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 70.87.28-239.opticalj:47521 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 70.87.28-129.opticalj:50422 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 inbound-us1.mailhostb:40181 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 ml-us1.mailhostbox.co:59585 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 59.162.86.172.static.:45826 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 70.87.28-100.opticalj:33912 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 mailbox-us-s-12.mailh:60741 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 mailbox-us-s-1.mailho:44171 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 70.87.28-102.opticalj:58455 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 70.87.29-211.opticalj:37865 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 mail.pw:44458 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 qmail-f-new.directi.c:50993 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 db-us2.mailhostbox.co:39248 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 srv1.chat.mail.pw:60231 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 webmail1.mailhostings:46764 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 server3.chat.pw:43060 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 server4.chat.pw:35751 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 70.87.28-130.opticalj:59470 CLOSE_WAIT 11925/ruby tcp 0 0 puppet:8140 mailbox-us-s-11.mailh:52888 ESTABLISHED 11925/ruby tcp 38 0 puppet:8140 mailbox-us-s-1.mailho:43617 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 70.87.28-105.opticalj:45961 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 mailbox-us-s-2a.mailh:41388 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 mailbox-us-s-2a.mailh:40870 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 cp-1.webhostbox.net:54237 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 srv2.chat.mail.pw:47643 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 db-us1.mailhostbox.co:44045 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 db-us4.mailhostbox.co:57891 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 70.87.28-129.opticalj:35373 CLOSE_WAIT 11925/ruby tcp 38 0 puppet:8140 mailbox-us-s-15.mailh:54860 CLOSE_WAIT 11925/ruby </pre> (reminds of http://projects.puppetlabs.com/issues/1095 ) I reverted back to stock CentOS RPMs for ruby, etc. + 2.6.1 RPMs of puppet from TMZ (http://tmz.fedorapeople.org/repo/puppet/epel/) and the problem persisted. Commenting out the queue-related config and async_storeconfigs didn't cause this problem anymore. Installed gem versions: <pre> #-(0)> gem list --local *** LOCAL GEMS *** actionmailer (2.3.8) actionpack (2.3.8) activerecord (2.3.8, 2.1.1) activeresource (2.3.8) activesupport (2.3.8, 2.1.1) facter (1.5.7) pg (0.9.0) puppet (2.6.0) rack (1.1.0) rails (2.3.8) rake (0.8.7) stomp (1.1.6) </pre> I'm not sure where this fits - the queueing part or the stored configuration part. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
