Hi, https://reductivelabs.com/trac/puppet/wiki/DocumentationStart https://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction https://reductivelabs.com/trac/puppet/wiki/PuppetMasters https://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice - Max
Matthew Palmer
2007-May-19 22:06 UTC
Re: Puppet Trac throwing errors again for documentation pages
On Sat, May 19, 2007 at 02:18:53PM -0400, Max wrote:> https://reductivelabs.com/trac/puppet/wiki/DocumentationStart > https://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction > https://reductivelabs.com/trac/puppet/wiki/PuppetMasters > https://reductivelabs.com/trac/puppet/wiki/PuppetBestPracticehttp://mail.madstop.com/pipermail/puppet-users/2007-May/002945.html I''m batting about 0.500 for tracebacks at the moment, but a reload of the page usually sorts it out. - Matt -- A byte walks into a bar and orders a pint. Bartender asks him "What''s wrong?" The byte says "Parity error." Bartender nods and says "Yeah, I thought you looked a bit off."
Benjamin C. Kite
2007-May-20 03:57 UTC
Re: Puppet Trac throwing errors again for documentation pages
On 19 May , 2007, at 18:06, Matthew Palmer wrote:> On Sat, May 19, 2007 at 02:18:53PM -0400, Max wrote: >> https://reductivelabs.com/trac/puppet/wiki/DocumentationStart >> https://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction >> https://reductivelabs.com/trac/puppet/wiki/PuppetMasters >> https://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice > > http://mail.madstop.com/pipermail/puppet-users/2007-May/002945.html > > I''m batting about 0.500 for tracebacks at the moment, but a reload > of the > page usually sorts it out.Unfortunately, we had to switch back to running trac with apache modules rather than tracd. Until we can get tracd running healthy on the old server or get things going on the new one, this problem will persist. Rest assured that this is a high priority for us.
Great project, no complaints here, just mentioned it in case someone was not aware it was still happening. On 5/19/07, Benjamin C. Kite <ben@reductivelabs.com> wrote:> > On 19 May , 2007, at 18:06, Matthew Palmer wrote: > > > On Sat, May 19, 2007 at 02:18:53PM -0400, Max wrote: > >> https://reductivelabs.com/trac/puppet/wiki/DocumentationStart > >> https://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction > >> https://reductivelabs.com/trac/puppet/wiki/PuppetMasters > >> https://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice > > > > http://mail.madstop.com/pipermail/puppet-users/2007-May/002945.html > > > > I''m batting about 0.500 for tracebacks at the moment, but a reload > > of the > > page usually sorts it out. > > > Unfortunately, we had to switch back to running trac with apache > modules rather than tracd. Until we can get tracd running healthy on > the old server or get things going on the new one, this problem will > persist. > > Rest assured that this is a high priority for us. > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
I''m progressivly building 36 Solaris servers - no more than 4 at a time. There is 1 puppetmaster. Periodically I''m seeing errors such as: May 21 10:35:48 guweb07 puppetd[7939]: [ID 702911 daemon.error] Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> May 21 10:35:48 guweb07 puppetd[7939]: [ID 702911 daemon.error] (//guweb07/common_solaris/solaris_common_config/solaris_default_login/gu_file[/etc/default/login]/File[/etc/default/login]/source) Could not describe /public/trunk/common-solaris/etc/default/login.guweb07: Connection reset by peer That example is one client throwing the error of 3 clients currently running. Sometimes it effectively ignores it and continues with the run. Occasionally it barfs and puts puppetd into maintenance mode so stopping the build. Worse; I left 4 servers building on Satudary evening and on Sunday morning one had completed while 3 had this error. May 20 12:04:42 guweb63 -- MARK -- May 20 12:05:04 guweb63 puppetd[1723]: [ID 702911 daemon.error] Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> nstall/admin/default: Connection reset by peer May 20 12:08:49 guweb63 puppetd[1723]: [ID 702911 daemon.error] Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> b63: Connection reset by peer May 20 12:12:33 guweb63 puppetd[1723]: [ID 702911 daemon.error] Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> .gnl: Connection reset by peer May 20 12:16:18 guweb63 puppetd[1723]: [ID 702911 daemon.error] Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> nection reset by peer May 20 12:20:03 guweb63 puppetd[1723]: [ID 702911 daemon.error] Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> May 20 12:20:03 guweb63 puppetd[1723]: [ID 702911 daemon.error] (//guweb63/common/common_tcp_wrappers_config/gu_file[/etc/hosts.deny]/File[/etc/hosts.deny]/source) Could not describe /public/trunk/common/etc/hosts.deny.guweb63: Connection reset by peer tcpdump showed the requests arriving at the puppetmaster and puppetmasterd serving the borked response. The only thing that was effective was to stop and restart both puppetd and puppetmasterd on the puppet master server. Now I''ve noticed that the Puppet Master itself is subject to similar errors. May 21 10:48:58 pupmst01 puppetd[10490]: Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> May 21 10:48:58 pupmst01 puppetd[10490]: (//pupmst01/common/common-role-users/gu_user[devsuprt]/gu_file[/home/devsuprt/.ssh/authorized_keys2]/File[/home/devsuprt/.ssh/authorized_keys2]/source) Could not describe /public/trunk/users/keys/devsuprt.pupmst01: May 21 10:50:09 pupmst01 puppetd[10490]: (//pupmst01/common/package_mount/Exec[umount /tmp/install]/returns) executed successfully May 21 10:50:10 pupmst01 puppetd[10490]: Finished configuration run in 1615.72 seconds May 21 10:55:15 pupmst01 puppetd[10490]: Starting configuration run The puppetmaster.log doesn''t show anything except re-opeing the log file when it''s restarted. I''ve searched the documentation site for "ECONNRESET" and "Connection reset by peer" with zero resuls while "702911" finds the not obviously applicable http://www.reductivelabs.com/trac/puppet/ticket/116 and http://www.reductivelabs.com/trac/puppet/ticket/129 The PM and svn behind it are Redhat Enterprise Linux with kernel 2.6.9-42 while the servers trying to build are Solaris 10 (118833-18). All are running Puppet 0.22 and Ruby 1.8.5-1 Matthew ------------------------------------------------------------------ Visit Guardian Unlimited - the UK''s most popular newspaper website http://guardian.co.uk http://observer.co.uk ------------------------------------------------------------------ The Newspaper Marketing Agency Opening Up Newspapers http://www.nmauk.co.uk ------------------------------------------------------------------ This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News & Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396 _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 21, 2007, at 6:25 AM, matthew.malthouse@guardian.co.uk wrote:> > I''m progressivly building 36 Solaris servers - no more than 4 at a > time. There is 1 puppetmaster. > > Periodically I''m seeing errors such as: > > May 21 10:35:48 guweb07 puppetd[7939]: [ID 702911 daemon.error] > Could not call fileserver.describe: #<Errno::ECONNRESET: Connection > reset by peer>This is an error thrown by the underlying libraries, which is why it doesn''t show up in the Puppet code itself. We''ve had reports of problems reporting ''end of file'' errors, but I haven''t heard of this many ''reset by peer'' errors. Is there any chance that you''re having network problems?> The puppetmaster.log doesn''t show anything except re-opeing the log > file when it''s restarted. > > I''ve searched the documentation site for "ECONNRESET" and > "Connection reset by peer" with zero resuls while "702911"As mentioned, the errors are from lower-level libraries, probably the http or ssl libraries, and the 702911 is from your system''s syslog library -- Puppet only provides the daemon/error info and the string, the rest of that line is produced by the system syslog library.> finds the not obviously applicable > http://www.reductivelabs.com/trac/puppet/ticket/116 and > http://www.reductivelabs.com/trac/puppet/ticket/129 > > > The PM and svn behind it are Redhat Enterprise Linux with kernel > 2.6.9-42 while the servers trying to build are Solaris 10 > (118833-18). All are running Puppet 0.22 and Ruby 1.8.5-1Literally 0.22.0? If so, it''d be best if you upgraded to 0.22.4 if possible. -- The Washington Bullets are changing their name. The owners no longer want their team''s name to be associated with crime. So from now on the team will be known as The Bullets. -- Paul Harvey, quoting Argus Hamilton --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
puppet-users-bounces@madstop.com wrote on 21/05/2007 18:48:11:> On May 21, 2007, at 6:25 AM, matthew.malthouse@guardian.co.uk wrote: > > I''m progressivly building 36 Solaris servers - no more than 4 at a > > time. There is 1 puppetmaster. > > > > Periodically I''m seeing errors such as: > > > > May 21 10:35:48 guweb07 puppetd[7939]: [ID 702911 daemon.error] > > Could not call fileserver.describe: #<Errno::ECONNRESET: Connection > > reset by peer> > > This is an error thrown by the underlying libraries, which is why it > doesn''t show up in the Puppet code itself. We''ve had reports of > problems reporting ''end of file'' errors, but I haven''t heard of this > many ''reset by peer'' errors. > > Is there any chance that you''re having network problems?That was a thought but I checked it out on Sunday and there didn''t seem to be. Nor was there any firewall obstruction. More than that the pupetmaster''s own puppetd shows the same problem connecting to itself: ie no network involved.> As mentioned, the errors are from lower-level libraries, probably the > http or ssl libraries, and the 702911 is from your system''s syslog > library -- Puppet only provides the daemon/error info and the string, > the rest of that line is produced by the system syslog library.> Literally 0.22.0? If so, it''d be best if you upgraded to 0.22.4 if > possible.Checked 0.22.4 on both the solaris client puppet machines and the linux puppetmaster. I did wonder if the over-size (1.6 Gb) /var/puppet/log/masterhttpd.log might have been a contributary factor but I''ve pruned and rotated that and the problem, although intermittant, persisits. Today''s example from the PuppetMaster, although I''ve seen it on the remote puppet clients more frequently. May 22 10:00:58 pupmst01 puppetd[571]: Starting configuration run May 22 10:11:57 pupmst01 puppetd[571]: Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> May 22 10:11:57 pupmst01 puppetd[571]: (//pupmst01/common/admin-users/gu_user[mbaker]/gu_file[/home/mbaker/.ssh/authorized_keys2]/File[/home/mbaker/.ssh/author ized_keys2]/source) Could not describe /public/trunk/users/keys/mbaker.pupmst01: Connection reset by peer May 22 10:12:39 pupmst01 puppetd[571]: (//pupmst01/common/package_mount/Exec[mount /tmp/install]/returns) executed successfully May 22 10:14:59 pupmst01 puppetd[571]: (//pupmst01/common/package_mount/Exec[umount /tmp/install]/returns) executed successfully May 22 10:16:19 pupmst01 puppetd[571]: Finished configuration run in 921.43 seconds May 22 10:21:31 pupmst01 puppetd[571]: Starting configuration run May 22 10:37:12 pupmst01 puppetd[571]: Could not call fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer> May 22 10:37:12 pupmst01 puppetd[571]: (//pupmst01/common/admin-users/gu_user[sgoldtho]/gu_file[/home/sgoldtho/.ssh/authorized_keys2]/File[/home/sgoldtho/.ssh/ authorized_keys2]/source) Could not describe /public/trunk/users/keys/sgoldtho.pupmst01: Connection reset by peer May 22 10:37:19 pupmst01 puppetd[571]: (//pupmst01/common/package_mount/Exec[mount /tmp/install]/returns) executed successfully May 22 10:39:54 pupmst01 puppetd[571]: (//pupmst01/common/package_mount/Exec[umount /tmp/install]/returns) executed successfully May 22 10:41:25 pupmst01 puppetd[571]: Finished configuration run in 1194.80 seconds My colleague Steve caught an strace on the PuppetMaster which I''m adding below. There''s a double close at the send, the second of which gets a bad file descriptor return. At the same time the client getrs a reset. But we have no idea if this is cause, consequence or coincidence. Matthew accept(7, {sa_family=AF_INET6, sin6_port=htons(32925), inet_pton(AF_INET6, "::ffff:192.168.16.100", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 11 fcntl64(11, F_GETFL) = 0x2 (flags O_RDWR) fstat64(11, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 _llseek(11, 0, 0xbfe108a4, SEEK_CUR) = -1 ESPIPE (Illegal seek) fcntl64(11, F_GETFL) = 0x2 (flags O_RDWR) fstat64(11, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 _llseek(11, 0, 0xbfe108a4, SEEK_CUR) = -1 ESPIPE (Illegal seek) fcntl64(11, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(11, F_SETFL, O_RDWR|O_NONBLOCK) = 0 read(11, "\200s\1\3\1\0Z\0\0\0\20", 11) = 11 read(11, "\0\0\26\0\0\23\0\0\n\7\0\300\0\0003\0\0002\0\0/\3\0\200"..., 106) = 106 write(11, "\26\3\1\0J\2\0\0F\3\1FQ\226\372\204o\7\362d\205B\0L\322"..., 1103) = 1103 read(11, 0x11ae4268, 5) = -1 EAGAIN (Resource temporarily unavailable) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 1 (in [10], left {0, 0}) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11 12], [], [], {0, 0}) = 1 (in [12], left {0, 0}) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11 12], [], [], {0, 0}) = 1 (in [12], left {0, 0}) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11 12], [], [], {0, 0}) = 1 (in [12], left {0, 0}) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [5], [], {0, 0}) = 1 (out [5], left {0, 0}) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [5], [], {0, 0}) = 1 (out [5], left {0, 0}) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [6], [], {0, 0}) = 1 (out [6], left {0, 0}) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 11], [6], [], {0, 0}) = 1 (out [6], left {0, 0}) select(13, [3 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 9 10 11], [], [], {0, 486229}) = 1 (in [9], left {0, 487000}) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [], [], {0, 0}) = 0 (Timeout) select(13, [3 10 11], [1], [], {0, 479351}) = 1 (out [1], left {0, 480000}) select(13, [3 10 11], [1], [], {0, 478905}) = 1 (out [1], left {0, 479000}) select(13, [3 10 11], [1], [], {0, 477025}) = 1 (out [1], left {0, 478000}) select(13, [3 10 11], [1], [], {0, 476411}) = 1 (out [1], left {0, 477000}) select(13, [3 10 11], [5], [], {0, 471335}) = 1 (out [5], left {0, 472000}) select(13, [3 10 11], [5], [], {0, 470573}) = 1 (out [5], left {0, 471000}) select(13, [3 10 11], [6], [], {0, 469187}) = 1 (out [6], left {0, 470000}) select(13, [3 10 11], [6], [], {0, 468609}) = 1 (out [6], left {0, 469000}) select(13, [3 9 10 11], [], [], {0, 467365}) = 1 (in [9], left {0, 445000}) select(13, [3 9 10 11], [], [], {0, 443725}) = 1 (in [9], left {0, 444000}) select(13, [3 10 11], [], [], {0, 437983}) = 1 (in [11], left {0, 425000}) read(11, "\26\3\1\4\206", 5) = 5 read(11, "\v\0\4\202\0\4\177\0\2L0\202\2H0\202\1\261\240\3\2\1\2"..., 1158) = 1158 read(11, "\26\3\1\0\206", 5) = 5 read(11, "\20\0\0\202\0\200c\266\361k\247\221\31\3548\241\304\251"..., 134) = 134 read(11, "\26\3\1\0\206", 5) = 5 read(11, "\17\0\0\202\0\200&vX\253\252l|0\244H\256\"S\340\27605\247"..., 134) = 134 read(11, "\24\3\1\0\1", 5) = 5 read(11, "\1", 1) = 1 read(11, "\26\3\1\0(", 5) = 5 read(11, "\27HT\213\335\0\222\205\24\223v\263+ \274\216\334M\314"..., 40) = 40 write(11, "\24\3\1\0\1\1\26\3\1\0(\360\2268Hx\370\16)P\''1\264&\r\5"..., 51) = 51 fcntl64(11, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) fcntl64(11, F_SETFL, O_RDWR|O_NONBLOCK) = 0 fcntl64(11, F_GETFD) = 0 getpeername(11, {sa_family=AF_INET6, sin6_port=htons(32925), inet_pton(AF_INET6, "::ffff:192.168.16.100", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 select(13, [3 10 11], [], [], {0, 0}) = 1 (in [11], left {0, 0}) select(12, [3 10 11], [], [], {0, 0}) = 1 (in [11], left {0, 0}) read(11, "\27\3\1\0\330", 5) = 5 read(11, "\235\253\4\373Q\365\270d\7\272*%\304\365\341\260i\f\231"..., 216) = 216 getpeername(11, {sa_family=AF_INET6, sin6_port=htons(32925), inet_pton(AF_INET6, "::ffff:192.168.16.100", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 getsockname(11, {sa_family=AF_INET6, sin6_port=htons(8140), inet_pton(AF_INET6, "::ffff:192.168.16.117", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 select(12, [3 9 10 11], [], [], {0, 313801}) = 1 (in [11], left {0, 314000}) read(11, "\27\3\1\1\30", 5) = 5 read(11, "fa\335\370\360\372\365\32]\234\350[[\7\17\345p\352\225"..., 280) = 280 write(1, "\33[0;31mnotice: mount[public]: Fi"..., 119) = 119 write(11, "\27\3\1\0\340g\262\222K,m)\2\371K\214,C\233\301\307\306"..., 229) = 229 write(11, "\27\3\1\0\220t\243fU\306E3\\\345)@d\t5-\31\204\335JE\275"..., 149) = 149 select(13, [3 9 10 11], [], [], {0, 291594}) = 1 (in [10], left {0, 273000}) select(13, [3 9 10 11], [], [], {0, 479207}) = 1 (in [10], left {0, 480000}) select(13, [3 9 11], [], [], {0, 470973}) = 1 (in [11], left {0, 461000}) select(12, [3 9 11], [], [], NULL) = 1 (in [11]) read(11, "\25\3\1\0\30", 5) = 5 read(11, "s\216X\257\304\33m!I2\274>\33P\253\265\361S\37\351\346"..., 24) = 24 write(11, "\25\3\1\0\30 \2551\"{\233\245\221i\326\0062\275\207\217"..., 29) = 29 close(11) = 0 close(11) = -1 EBADF (Bad file descriptor) select(11, [3 9], [], [], NULL) = 1 (in [9]) ------------------------------------------------------------------ Visit Guardian Unlimited - the UK''s most popular newspaper website http://guardian.co.uk http://observer.co.uk ------------------------------------------------------------------ The Newspaper Marketing Agency Opening Up Newspapers http://www.nmauk.co.uk ------------------------------------------------------------------ This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News & Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396 _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 22, 2007, at 9:02 AM, matthew.malthouse@guardian.co.uk wrote:> > That was a thought but I checked it out on Sunday and there didn''t > seem to be. Nor was there any firewall obstruction. > > More than that the pupetmaster''s own puppetd shows the same problem > connecting to itself: ie no network involved.Very strange. I wonder if this problem is related to the ''end of file'' problems a couple of people are experiencing.> Checked 0.22.4 on both the solaris client puppet machines and the > linux puppetmaster.Ok.> I did wonder if the over-size (1.6 Gb) /var/puppet/log/ > masterhttpd.log might have been a contributary factor but I''ve > pruned and rotated that and the problem, although intermittant, > persisits.Good to know you''re being thorough.> Today''s example from the PuppetMaster, although I''ve seen it on the > remote puppet clients more frequently. > > May 22 10:00:58 pupmst01 puppetd[571]: Starting configuration run > May 22 10:11:57 pupmst01 puppetd[571]: Could not call > fileserver.describe: #<Errno::ECONNRESET: Connection reset by peer>This could possibly be happening because you''ve got too many clients connecting. Does it happen when there are no other clients connecting? It seems like you''re getting a lot of connections, if your server log got that big. I''d like to help you get the master running in mongrel behind apache and see if that fixes your problem. It should support many more concurrent connections, and it seems like maybe WEBrick is dumbing connections that come in when the queue is full.> My colleague Steve caught an strace on the PuppetMaster which I''m > adding below. > > There''s a double close at the send, the second of which gets a bad > file descriptor return. > > At the same time the client getrs a reset. But we have no idea if > this is cause, consequence or coincidence.Huh. I wouldn''t think that''s the problem, since the client''s connection has already been closed. I expect that''s just bad programming in WEBrick. -- A government that robs Peter to pay Paul can always depend on the support of Paul. -- George Bernard Shaw --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com