From janetmason@example.net Sat May 01 13:30:04 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 15991 invoked by uid 6000); 1 May 1999 13:30:03 -0000 Received: (qmail 15974 invoked by uid 2001); 1 May 1999 13:30:01 -0000 Received:(qmail 15798 invoked by uid 2012); 1 May 1999 13:28:16 -0000 Message-Id:<janetmason@example.net> Date:1 May 1999 13:28:16 -0000 From: Gary Goldberg <janetmason@example.net> Reply-To: janetmason@example.net To: janetmason@example.net X-Send-Pr-Version:3.2 Subject: config/4341: ErrorDocument directive ignored in virtual host definitions Sender: janetmason@example.net Precedence: bulk >Number: 4341 >Category: config >Synopsis: ErrorDocument directive ignored in virtual host definitions >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sat May 1 06:30:01 PDT 1999 >Last-Modified: >Originator: janetmason@example.net >Organization: apache >Release: 1.3.6 >Environment: Solaris 7 X86 base rev, egcs 1.1.2 athena# uname -a SunOS athena 5.7 Generic i86pc i386 i86pc >Description: This is similar to a problem I reported and was corrected for an earlier version. I have host-based virtual hosts configured, and the ErrorDocument directive for the first virtual host defined is being used for all virtual hosts. >How-To-Repeat: http://www.netlondon.com/ and enter a search term and submit. It won't find it, and instead of returning a 404 error page for netlondon, it returns the ErrorDocument for snpp.com, which is the first defined VirtualHost in the httpd.conf. >Fix: It may be as simple as reapplying the original fix, perhaps it got lost in an RCS revision? Thanks in any case. -Gary >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] From janetmason@example.net Sat May 01 13:30:13 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 16065 invoked by uid 6000); 1 May 1999 13:30:11 -0000 Received: (qmail 15974 invoked by uid 2001); 1 May 1999 13:30:01 -0000 Received:(qmail 15798 invoked by uid 2012); 1 May 1999 13:28:16 -0000 Message-Id:<janetmason@example.net> Date:1 May 1999 13:28:16 -0000 From: Gary Goldberg <janetmason@example.net> Reply-To: janetmason@example.net To: janetmason@example.net X-Send-Pr-Version:3.2 Subject: config/4341: ErrorDocument directive ignored in virtual host definitions Sender: janetmason@example.net Precedence: bulk >Number: 4341 >Category: config >Synopsis: ErrorDocument directive ignored in virtual host definitions >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sat May 1 06:30:01 PDT 1999 >Last-Modified: >Originator: janetmason@example.net >Organization: apache >Release: 1.3.6 >Environment: Solaris 7 X86 base rev, egcs 1.1.2 athena# uname -a SunOS athena 5.7 Generic i86pc i386 i86pc >Description: This is similar to a problem I reported and was corrected for an earlier version. I have host-based virtual hosts configured, and the ErrorDocument directive for the first virtual host defined is being used for all virtual hosts. >How-To-Repeat: http://www.netlondon.com/ and enter a search term and submit. It won't find it, and instead of returning a 404 error page for netlondon, it returns the ErrorDocument for snpp.com, which is the first defined VirtualHost in the httpd.conf. >Fix: It may be as simple as reapplying the original fix, perhaps it got lost in an RCS revision? Thanks in any case. -Gary >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] From janetmason@example.net Sat May 01 13:40:02 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 18175 invoked by uid 6000); 1 May 1999 13:40:02 -0000 Received: (qmail 18165 invoked by uid 2001); 1 May 1999 13:40:00 -0000 Received:(qmail 17553 invoked by uid 2012); 1 May 1999 13:38:09 -0000 Message-Id:<janetmason@example.net> Date:1 May 1999 13:38:09 -0000 From: Jean-Hugue Royer <janetmason@example.net> Reply-To: janetmason@example.net To: janetmason@example.net X-Send-Pr-Version:3.2 Subject: general/4342: MaxRequestsPerChild doesn't match server-status access number per child Sender: janetmason@example.net Precedence: bulk >Number: 4342 >Category: general >Synopsis: MaxRequestsPerChild doesn't match server-status access number per child >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sat May 1 06:40:00 PDT 1999 >Last-Modified: >Originator: janetmason@example.net >Organization: apache >Release: 1.3.6 >Environment: QNX 4.25 , Watcom 10.6 >Description: When setting MaxRequestsPerChild to "200" for example, if you look the server-status you can see that number of accesses per child can go up to "500" , it seems that either MaxRequestsPerCild is not applied or the number of accesses per child of server-status is not accurate. >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] From janetmason@example.net Sat May 01 13:40:11 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 18239 invoked by uid 6000); 1 May 1999 13:40:10 -0000 Received: (qmail 18165 invoked by uid 2001); 1 May 1999 13:40:00 -0000 Received:(qmail 17553 invoked by uid 2012); 1 May 1999 13:38:09 -0000 Message-Id:<janetmason@example.net> Date:1 May 1999 13:38:09 -0000 From: Jean-Hugue Royer <janetmason@example.net> Reply-To: janetmason@example.net To: janetmason@example.net X-Send-Pr-Version:3.2 Subject: general/4342: MaxRequestsPerChild doesn't match server-status access number per child Sender: janetmason@example.net Precedence: bulk >Number: 4342 >Category: general >Synopsis: MaxRequestsPerChild doesn't match server-status access number per child >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sat May 1 06:40:00 PDT 1999 >Last-Modified: >Originator: janetmason@example.net >Organization: apache >Release: 1.3.6 >Environment: QNX 4.25 , Watcom 10.6 >Description: When setting MaxRequestsPerChild to "200" for example, if you look the server-status you can see that number of accesses per child can go up to "500" , it seems that either MaxRequestsPerCild is not applied or the number of accesses per child of server-status is not accurate. >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] From janetmason@example.net Sat May 01 15:30:04 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 5763 invoked by uid 6000); 1 May 1999 15:30:03 -0000 Received: (qmail 5748 invoked by uid 2001); 1 May 1999 15:30:01 -0000 Received:(qmail 4553 invoked by uid 2012); 1 May 1999 15:26:08 -0000 Message-Id:<janetmason@example.net> Date:1 May 1999 15:26:08 -0000 From: Eugenia Harris <janetmason@example.net> Reply-To: janetmason@example.net To: janetmason@example.net X-Send-Pr-Version:3.2 Subject: other/4343: Activating a new module as a DSO Sender: janetmason@example.net Precedence: bulk >Number: 4343 >Category: other >Synopsis: Activating a new module as a DSO >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: change-request >Submitter-Id: apache >Arrival-Date: Sat May 1 08:30:00 PDT 1999 >Last-Modified: >Originator: janetmason@example.net >Organization: apache >Release: 1.3.6 >Environment: Solaris 2.5 -- Generic_103093-25 sun4u sparc SUNW,Ultra-1 >Description: The configure script doesn't seem to support activating a new module as a DSO. I tried various combinations of the --activate-module and --enable-shared options to no avail. >How-To-Repeat: My scenario consisted of creating a src/modules/blah directory with the right stuff to build libblah.so and then running configure as follows: ./configure --shadow --enable-module=so --enable-module=most \ --enable-shared=proxy --activate-module=src/modules/blah/libblah.so \ --enable-shared=blah >Fix: I got around it by adding an --activate-shared option. My bloated implementation duplicates the --activate-module code, with a few small changes, and works for me on Solaris like this: ./configure --shadow --enable-module=so --enable-module=most \ --enable-shared=proxy --activate-shared=src/modules/blah/libblah.so The only changes over --with-activate-module are: > echo "## (configure --activate-shared=$file)" >>$addconf > echo "SharedModule $modfile" >>$addconf and: > eval "shared_$module=yes" >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] From janetmason@example.net Sat May 01 15:30:08 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 5835 invoked by uid 6000); 1 May 1999 15:30:06 -0000 Received: (qmail 5748 invoked by uid 2001); 1 May 1999 15:30:01 -0000 Received:(qmail 4553 invoked by uid 2012); 1 May 1999 15:26:08 -0000 Message-Id:<janetmason@example.net> Date:1 May 1999 15:26:08 -0000 From: Eugenia Harris <janetmason@example.net> Reply-To: janetmason@example.net To: janetmason@example.net X-Send-Pr-Version:3.2 Subject: other/4343: Activating a new module as a DSO Sender: janetmason@example.net Precedence: bulk >Number: 4343 >Category: other >Synopsis: Activating a new module as a DSO >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: change-request >Submitter-Id: apache >Arrival-Date: Sat May 1 08:30:00 PDT 1999 >Last-Modified: >Originator: janetmason@example.net >Organization: apache >Release: 1.3.6 >Environment: Solaris 2.5 -- Generic_103093-25 sun4u sparc SUNW,Ultra-1 >Description: The configure script doesn't seem to support activating a new module as a DSO. I tried various combinations of the --activate-module and --enable-shared options to no avail. >How-To-Repeat: My scenario consisted of creating a src/modules/blah directory with the right stuff to build libblah.so and then running configure as follows: ./configure --shadow --enable-module=so --enable-module=most \ --enable-shared=proxy --activate-module=src/modules/blah/libblah.so \ --enable-shared=blah >Fix: I got around it by adding an --activate-shared option. My bloated implementation duplicates the --activate-module code, with a few small changes, and works for me on Solaris like this: ./configure --shadow --enable-module=so --enable-module=most \ --enable-shared=proxy --activate-shared=src/modules/blah/libblah.so The only changes over --with-activate-module are: > echo "## (configure --activate-shared=$file)" >>$addconf > echo "SharedModule $modfile" >>$addconf and: > eval "shared_$module=yes" >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] From janetmason@example.net Sat May 01 17:03:55 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 28350 invoked by uid 6000); 1 May 1999 17:03:53 -0000 Received: (qmail 28326 invoked by uid 143); 1 May 1999 17:03:51 -0000 Date: 1 May 1999 17:03:51 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: mod_proxy/3178: Access Violation/SEGV in ap_proxy_cache_error Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Access Violation/SEGV in ap_proxy_cache_error State-Changed-From-To: open-closed State-Changed-By: dgaudet State-Changed-When: Sat May 1 10:03:48 PDT 1999 State-Changed-Why: A patch has been committed to 1.3.7, thanks. From janetmason@example.net Sat May 01 17:17:02 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 1212 invoked by uid 6000); 1 May 1999 17:17:01 -0000 Received: (qmail 1193 invoked by uid 143); 1 May 1999 17:17:00 -0000 Date: 1 May 1999 17:17:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: config/3661: 'make install' ignores the --prefix dir specified during configuration Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: 'make install' ignores the --prefix dir specified during configuration State-Changed-From-To: feedback-closed State-Changed-By: dgaudet State-Changed-When: Sat May 1 10:16:59 PDT 1999 State-Changed-Why: User reports the problem is fixed in 1.3.6. From janetmason@example.net Sat May 01 17:20:02 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 1548 invoked by uid 6000); 1 May 1999 17:20:01 -0000 Received: (qmail 1539 invoked by uid 2001); 1 May 1999 17:20:00 -0000 Date: 1 May 1999 17:20:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: RE: protocol/3993: Incomplete Pages Loading Randomly (fwd) Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR protocol/3993; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: janetmason@example.net Cc: Subject: RE: protocol/3993: Incomplete Pages Loading Randomly (fwd) Date: Sat, 1 May 1999 10:15:52 -0700 (PDT) ---------- Forwarded message ---------- From: Darron Smith <janetmason@example.net> To: janetmason@example.net Subject: RE: protocol/3993: Incomplete Pages Loading Randomly Date: Wed, 21 Apr 1999 12:38:53 +0100 It seems to indeed be a problem with incomplete packets. In particular something called TCP slow start. This is where when an initial connection is made between client and server the number of packets sent at once is slowly built up. This is where I ran into problems with my little Solaris server on the very large BBC WAN (Probably the largest single Network in the world with up to 50,000 devices connected to it). The default network set up for a Solaris 2.6 box is for a small LAN of about 10 units. Basically I had to do a little "ndd" tweaking of the device drivers in particular "ndd -set /dev/tcp tcp_slow_start_initial 2" to increase the number of initial packets sent out as there is an packet ACK problem in windows 95/IE 3.01 with HTTP 1.0 protocols. It seems to have cured most of the problem. Darron From janetmason@example.net Sat May 01 17:20:06 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 1611 invoked by uid 6000); 1 May 1999 17:20:05 -0000 Received: (qmail 1539 invoked by uid 2001); 1 May 1999 17:20:00 -0000 Date: 1 May 1999 17:20:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: RE: protocol/3993: Incomplete Pages Loading Randomly (fwd) Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR protocol/3993; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: janetmason@example.net Cc: Subject: RE: protocol/3993: Incomplete Pages Loading Randomly (fwd) Date: Sat, 1 May 1999 10:15:52 -0700 (PDT) ---------- Forwarded message ---------- From: Darron Smith <janetmason@example.net> To: janetmason@example.net Subject: RE: protocol/3993: Incomplete Pages Loading Randomly Date: Wed, 21 Apr 1999 12:38:53 +0100 It seems to indeed be a problem with incomplete packets. In particular something called TCP slow start. This is where when an initial connection is made between client and server the number of packets sent at once is slowly built up. This is where I ran into problems with my little Solaris server on the very large BBC WAN (Probably the largest single Network in the world with up to 50,000 devices connected to it). The default network set up for a Solaris 2.6 box is for a small LAN of about 10 units. Basically I had to do a little "ndd" tweaking of the device drivers in particular "ndd -set /dev/tcp tcp_slow_start_initial 2" to increase the number of initial packets sent out as there is an packet ACK problem in windows 95/IE 3.01 with HTTP 1.0 protocols. It seems to have cured most of the problem. Darron From janetmason@example.net Sat May 01 17:30:03 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 3385 invoked by uid 6000); 1 May 1999 17:30:03 -0000 Received: (qmail 3355 invoked by uid 2001); 1 May 1999 17:30:00 -0000 Date: 1 May 1999 17:30:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR os-linux/4268; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: Karthik Prabhakar <janetmason@example.net> Cc: janetmason@example.net, janetmason@example.net Subject: Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist Date: Sat, 1 May 1999 10:24:48 -0700 (PDT) On Thu, 22 Apr 1999, Karthik Prabhakar wrote: > >From the strace, it appears that the read() from the socket is > taking a bit of time, as well as the flock(). the flock() is not abnormal -- it's used for interprocess synchronization. The read() is also probably not a problem... it's usually client latency. I'm not sure what's up... I'm actually going to have a chance to test this stuff out on a high end linux box under specweb this weekend I think. So I may be able to repeat it. Dean From janetmason@example.net Sat May 01 17:30:04 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 3388 invoked by uid 6000); 1 May 1999 17:30:03 -0000 Received: (qmail 3355 invoked by uid 2001); 1 May 1999 17:30:00 -0000 Date: 1 May 1999 17:30:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR os-linux/4268; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: Karthik Prabhakar <janetmason@example.net> Cc: janetmason@example.net, janetmason@example.net Subject: Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist Date: Sat, 1 May 1999 10:24:48 -0700 (PDT) On Thu, 22 Apr 1999, Karthik Prabhakar wrote: > >From the strace, it appears that the read() from the socket is > taking a bit of time, as well as the flock(). the flock() is not abnormal -- it's used for interprocess synchronization. The read() is also probably not a problem... it's usually client latency. I'm not sure what's up... I'm actually going to have a chance to test this stuff out on a high end linux box under specweb this weekend I think. So I may be able to repeat it. Dean From janetmason@example.net Sat May 01 17:30:06 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 3450 invoked by uid 6000); 1 May 1999 17:30:05 -0000 Received: (qmail 3362 invoked by uid 2001); 1 May 1999 17:30:01 -0000 Date: 1 May 1999 17:30:01 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: Re: general/4160: Reading large amounts of data Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR general/4160; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: Peter Gordon <janetmason@example.net> Cc: janetmason@example.net Subject: Re: general/4160: Reading large amounts of data Date: Sat, 1 May 1999 10:27:23 -0700 (PDT) On Thu, 22 Apr 1999, Peter Gordon wrote: > This is where I am having a problem. From having a look at the source, > it looks as if it goes out of its way to limit the size of the > incoming information. It limits the incoming URI. You can't use URIs more than about 512 bytes without messing up older browsers, so there are various practical limits. Apache will handle up to about an 8k URI. > When I POST less than 8K, the transfer works > successfully. When I post more, I get the error message I don't understand how your POST is generating a huge URI. This is outside Apache's control. POST should generate a request body, and not change the URI. Or perhaps your script is generating a massive URI in the action="" field. If so, then I suggest you move some of the data in that URI into hidden fields. Dean From janetmason@example.net Sat May 01 17:30:10 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 3578 invoked by uid 6000); 1 May 1999 17:30:08 -0000 Received: (qmail 3362 invoked by uid 2001); 1 May 1999 17:30:01 -0000 Date: 1 May 1999 17:30:01 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: Re: general/4160: Reading large amounts of data Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR general/4160; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: Peter Gordon <janetmason@example.net> Cc: janetmason@example.net Subject: Re: general/4160: Reading large amounts of data Date: Sat, 1 May 1999 10:27:23 -0700 (PDT) On Thu, 22 Apr 1999, Peter Gordon wrote: > This is where I am having a problem. From having a look at the source, > it looks as if it goes out of its way to limit the size of the > incoming information. It limits the incoming URI. You can't use URIs more than about 512 bytes without messing up older browsers, so there are various practical limits. Apache will handle up to about an 8k URI. > When I POST less than 8K, the transfer works > successfully. When I post more, I get the error message I don't understand how your POST is generating a huge URI. This is outside Apache's control. POST should generate a request body, and not change the URI. Or perhaps your script is generating a massive URI in the action="" field. If so, then I suggest you move some of the data in that URI into hidden fields. Dean From janetmason@example.net Sat May 01 17:33:32 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 4370 invoked by uid 6000); 1 May 1999 17:33:30 -0000 Received: (qmail 4351 invoked by uid 143); 1 May 1999 17:33:29 -0000 Date: 1 May 1999 17:33:29 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: config/3714: Make returns a elf error message Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Make returns a elf error message State-Changed-From-To: feedback-closed State-Changed-By: dgaudet State-Changed-When: Sat May 1 10:33:28 PDT 1999 State-Changed-Why: user reports gcc misconfiguration From janetmason@example.net Sat May 01 17:39:05 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 5520 invoked by uid 6000); 1 May 1999 17:39:04 -0000 Received: (qmail 5500 invoked by uid 143); 1 May 1999 17:39:02 -0000 Date: 1 May 1999 17:39:02 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-linux/3312: Children die. Parent stops serving requests Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Children die. Parent stops serving requests State-Changed-From-To: feedback-analyzed State-Changed-By: dgaudet State-Changed-When: Sat May 1 10:39:02 PDT 1999 State-Changed-Why: I examined the straces a while ago, but forgot to comment. Here's a portion of the parent's trace: time(NULL) = 909702870 wait4(-1, 0xbffffe64, WNOHANG, NULL) = 0 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) time(NULL) = 909702871 fork() = 26032 wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WNOHANG, NULL) = 26032 --- SIGCHLD (Child exited) --- wait4(-1, 0xbffffe64, WNOHANG, NULL) = -1 ECHILD (No child processes) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) time(NULL) = 909703113 Somehow 242 seconds passed between the two time() calls... the parent does nothing cpu intensive, so I doubt it's that. It's possible the guy's box is swapping to hell... but we've got about a dozen similar reports. The reports are against 2.0.30, 2.0.32, and 2.0.33. Oh then there's the odd SIGCHLD followed by ECHILD... there's a few other instances of that -- SIGCHLDs happenning and wait4() not reporting anything. The short answer: kernel problem. Alan Cox hasn't heard of this problem before, so it's probably an unknown problem. Dean From janetmason@example.net Sat May 01 17:40:10 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 5679 invoked by uid 6000); 1 May 1999 17:40:09 -0000 Received: (qmail 5665 invoked by uid 2001); 1 May 1999 17:40:06 -0000 Date: 1 May 1999 17:40:06 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: Re: general/4224: I get an inconsistend error, incomplete header sent error, but it works fine with ALL other browsers Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR general/4224; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: John Saario <janetmason@example.net> Cc: janetmason@example.net Subject: Re: general/4224: I get an inconsistend error, incomplete header sent error, but it works fine with ALL other browsers Date: Sat, 1 May 1999 10:31:48 -0700 (PDT) Oh, you're running apache in inetd mode? That mode probably has bugs... in fact I'm about to remove it from the server. Try running apache in standalone mode please. Dean On Wed, 28 Apr 1999, John Saario wrote: > Dean > > I tried that by upgrading to apache 1.3.6 ... and putting in a no-keep alive for > IE 5.0 but same result. > > KeepAlive On > MaxKeepAliveRequests 100 > KeepAliveTimeout 15 > BrowserMatch "Mozilla/2" nokeepalive > BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 > BrowserMatch "MSIE 5\.0;" nokeepalive downgrade-1.0 force-response-1.0 > > As long as I don't need to change any auth settings from default this should work? > > Worse, and I have not yet reported this yet, but after 3 days apache 1.3.6 causes inetd > to lock up on FreeBSD .. I tried this both on FreeBSD 3.0 and 2.2.6. If I try to login > via telnet inetd bails with some pointer too low error. Restarting apache from the > console doesn't fix it. Hup of inetd doesn't fix it, but killing inetd and restarting it > does fix it. Of course server reboot will fix it as well. But anyway it doesn't show up > on my servers for about 3 days that boom, locked out. Pretty serious for me since I > am in Singapore and 5 of my servers are in the USA. Anyway, hope you can forward > that on. Still getting the "incomplete header information for all the IE 5.0 clients". > I switched back to apache_1.1.1 because of the inetd problem. > > I didn't notice 1.3.6 seems to be as fast as older versions of apache and that is why > I liked it and upgraded ... I'll be watching for the next release to see if it's fixed since > I know most my servers are running very old ( but faster ) versions. From janetmason@example.net Sat May 01 17:40:14 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 5752 invoked by uid 6000); 1 May 1999 17:40:13 -0000 Received: (qmail 5665 invoked by uid 2001); 1 May 1999 17:40:06 -0000 Date: 1 May 1999 17:40:06 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: Re: general/4224: I get an inconsistend error, incomplete header sent error, but it works fine with ALL other browsers Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR general/4224; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: John Saario <janetmason@example.net> Cc: janetmason@example.net Subject: Re: general/4224: I get an inconsistend error, incomplete header sent error, but it works fine with ALL other browsers Date: Sat, 1 May 1999 10:31:48 -0700 (PDT) Oh, you're running apache in inetd mode? That mode probably has bugs... in fact I'm about to remove it from the server. Try running apache in standalone mode please. Dean On Wed, 28 Apr 1999, John Saario wrote: > Dean > > I tried that by upgrading to apache 1.3.6 ... and putting in a no-keep alive for > IE 5.0 but same result. > > KeepAlive On > MaxKeepAliveRequests 100 > KeepAliveTimeout 15 > BrowserMatch "Mozilla/2" nokeepalive > BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 > BrowserMatch "MSIE 5\.0;" nokeepalive downgrade-1.0 force-response-1.0 > > As long as I don't need to change any auth settings from default this should work? > > Worse, and I have not yet reported this yet, but after 3 days apache 1.3.6 causes inetd > to lock up on FreeBSD .. I tried this both on FreeBSD 3.0 and 2.2.6. If I try to login > via telnet inetd bails with some pointer too low error. Restarting apache from the > console doesn't fix it. Hup of inetd doesn't fix it, but killing inetd and restarting it > does fix it. Of course server reboot will fix it as well. But anyway it doesn't show up > on my servers for about 3 days that boom, locked out. Pretty serious for me since I > am in Singapore and 5 of my servers are in the USA. Anyway, hope you can forward > that on. Still getting the "incomplete header information for all the IE 5.0 clients". > I switched back to apache_1.1.1 because of the inetd problem. > > I didn't notice 1.3.6 seems to be as fast as older versions of apache and that is why > I liked it and upgraded ... I'll be watching for the next release to see if it's fixed since > I know most my servers are running very old ( but faster ) versions. From janetmason@example.net Sat May 01 17:41:28 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 5950 invoked by uid 6000); 1 May 1999 17:41:25 -0000 Received: (qmail 5927 invoked by uid 143); 1 May 1999 17:41:22 -0000 Date: 1 May 1999 17:41:22 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-linux/2986: after log rotation restart, all children die in hours. Parent is catatonic. Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: after log rotation restart, all children die in hours. Parent is catatonic. State-Changed-From-To: feedback-analyzed State-Changed-By: dgaudet State-Changed-When: Sat May 1 10:41:20 PDT 1999 State-Changed-Why: This sounds like the same kernel bug described in 3312: http://bugs.apache.org/index/full/3312 no solution known Dean From janetmason@example.net Sat May 01 17:43:17 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 6283 invoked by uid 6000); 1 May 1999 17:43:16 -0000 Received: (qmail 6263 invoked by uid 143); 1 May 1999 17:43:14 -0000 Date: 1 May 1999 17:43:14 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Server dies after 1-20 hours of usage. State-Changed-From-To: feedback-analyzed State-Changed-By: dgaudet State-Changed-When: Sat May 1 10:43:13 PDT 1999 State-Changed-Why: This sounds like the same kernel bug as reported in PR#3312: http://bugs.apache.org/index/full/3312 no workaround known at the moment Dean From janetmason@example.net Sat May 01 17:49:40 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 7270 invoked by uid 6000); 1 May 1999 17:49:39 -0000 Received: (qmail 7248 invoked by uid 143); 1 May 1999 17:49:37 -0000 Date: 1 May 1999 17:49:37 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Server dies after 1-20 hours of usage. State-Changed-From-To: analyzed-feedback State-Changed-By: dgaudet State-Changed-When: Sat May 1 10:49:35 PDT 1999 State-Changed-Why: Hey are you still having this problem? You indicated that it happens when some mailing list cron job runs. Do you use sendmail or qmail? When the problem happens, could you use "strace -p pid_of_parent" to find out what the parent is doing and mail me the output? Thanks Dean From janetmason@example.net Sat May 01 17:50:03 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 7384 invoked by uid 6000); 1 May 1999 17:50:02 -0000 Received: (qmail 7374 invoked by uid 2001); 1 May 1999 17:50:00 -0000 Date: 1 May 1999 17:50:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. (fwd) Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR os-linux/3343; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: janetmason@example.net Cc: Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. (fwd) Date: Sat, 1 May 1999 10:41:56 -0700 (PDT) ---------- Forwarded message ---------- Date: Wed, 17 Mar 1999 12:13:59 -0600 From: Darrin Martin <janetmason@example.net> To: janetmason@example.net Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. As per your request, the following is the netstat -nt command issued after the server hung... [root@www /root]# netstat -nt Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 368 0 83.161.120.155:80 83.161.120.155:6337 CLOSE_WAIT tcp 368 0 83.161.120.155:80 83.161.120.155:6326 CLOSE_WAIT tcp 391 0 83.161.120.155:80 83.161.120.155:3458 CLOSE_WAIT tcp 416 0 83.161.120.155:80 83.161.120.155:46679 ESTABLISHED tcp 343 0 83.161.120.155:80 83.161.120.155:48871 CLOSE_WAIT tcp 311 0 83.161.120.155:80 83.161.120.155:2072 CLOSE tcp 391 0 83.161.120.155:80 83.161.120.155:3459 CLOSE_WAIT tcp 311 0 83.161.120.155:80 83.161.120.155:2073 CLOSE tcp 289 0 83.161.120.155:80 83.161.120.155:2060 CLOSE tcp 322 0 83.161.120.155:80 83.161.120.155:3066 CLOSE_WAIT tcp 311 0 83.161.120.155:80 83.161.120.155:2074 CLOSE tcp 416 0 83.161.120.155:80 83.161.120.155:46680 ESTABLISHED tcp 1715 0 83.161.120.155:80 83.161.120.155:3460 CLOSE_WAIT tcp 140 0 83.161.120.155:80 83.161.120.155:2155 ESTABLISHED tcp 289 0 83.161.120.155:80 83.161.120.155:2061 CLOSE tcp 270 0 83.161.120.155:80 83.161.120.155:3094 CLOSE_WAIT tcp 289 0 83.161.120.155:80 83.161.120.155:2062 CLOSE tcp 320 0 83.161.120.155:80 83.161.120.155:23279 CLOSE_WAIT tcp 343 0 83.161.120.155:80 83.161.120.155:60184 CLOSE_WAIT tcp 391 0 83.161.120.155:80 83.161.120.155:3461 CLOSE_WAIT tcp 264 0 83.161.120.155:80 83.161.120.155:34452 CLOSE_WAIT tcp 348 0 83.161.120.155:80 83.161.120.155:2073 ESTABLISHED tcp 0 0 83.161.120.155:80 83.161.120.155:3462 ESTABLISHED tcp 385 0 83.161.120.155:80 83.161.120.155:3463 CLOSE_WAIT tcp 264 0 83.161.120.155:80 83.161.120.155:34554 CLOSE_WAIT tcp 0 124 83.161.120.155:23 83.161.120.155:3243 ESTABLISHED tcp 241 0 83.161.120.155:80 83.161.120.155:3471 ESTABLISHED tcp 342 0 83.161.120.155:80 83.161.120.155:6924 ESTABLISHED Also, please be aware of the fact that the problem seemed to have changed when we upgraded to the Redhat 5.2rpm version of Apache...... now, instead of crashing every 20-24 hours, it is not expiring all requests, and eventually will lock up all available processes... I'll try and include a copy or you can view it yourself at http://www.v6fbody.com/server-status Login:apache Password:group Thank you. Darrin Martin -------snip--------- Comment-Added-By: dgaudet Comment-Added-When: Tue Mar 16 08:34:26 PST 1999 Comment-Added: When the problem happens, do a "netstat -nt" -- that should show to where the ESTABLISHED port 80 connections are ... I suspect something is just holding connections open. If that doesn't help, use "strace" on a few of the children to see what they're doing: strace -p pid_of_child Dean From janetmason@example.net Sat May 01 17:50:03 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 7387 invoked by uid 6000); 1 May 1999 17:50:02 -0000 Received: (qmail 7374 invoked by uid 2001); 1 May 1999 17:50:00 -0000 Date: 1 May 1999 17:50:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Dean Gaudet <janetmason@example.net> Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. (fwd) Reply-To: Dean Gaudet <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR os-linux/3343; it has been noted by GNATS. From: Dean Gaudet <janetmason@example.net> To: janetmason@example.net Cc: Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. (fwd) Date: Sat, 1 May 1999 10:41:56 -0700 (PDT) ---------- Forwarded message ---------- Date: Wed, 17 Mar 1999 12:13:59 -0600 From: Darrin Martin <janetmason@example.net> To: janetmason@example.net Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. As per your request, the following is the netstat -nt command issued after the server hung... [root@www /root]# netstat -nt Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 368 0 83.161.120.155:80 83.161.120.155:6337 CLOSE_WAIT tcp 368 0 83.161.120.155:80 83.161.120.155:6326 CLOSE_WAIT tcp 391 0 83.161.120.155:80 83.161.120.155:3458 CLOSE_WAIT tcp 416 0 83.161.120.155:80 83.161.120.155:46679 ESTABLISHED tcp 343 0 83.161.120.155:80 83.161.120.155:48871 CLOSE_WAIT tcp 311 0 83.161.120.155:80 83.161.120.155:2072 CLOSE tcp 391 0 83.161.120.155:80 83.161.120.155:3459 CLOSE_WAIT tcp 311 0 83.161.120.155:80 83.161.120.155:2073 CLOSE tcp 289 0 83.161.120.155:80 83.161.120.155:2060 CLOSE tcp 322 0 83.161.120.155:80 83.161.120.155:3066 CLOSE_WAIT tcp 311 0 83.161.120.155:80 83.161.120.155:2074 CLOSE tcp 416 0 83.161.120.155:80 83.161.120.155:46680 ESTABLISHED tcp 1715 0 83.161.120.155:80 83.161.120.155:3460 CLOSE_WAIT tcp 140 0 83.161.120.155:80 83.161.120.155:2155 ESTABLISHED tcp 289 0 83.161.120.155:80 83.161.120.155:2061 CLOSE tcp 270 0 83.161.120.155:80 83.161.120.155:3094 CLOSE_WAIT tcp 289 0 83.161.120.155:80 83.161.120.155:2062 CLOSE tcp 320 0 83.161.120.155:80 83.161.120.155:23279 CLOSE_WAIT tcp 343 0 83.161.120.155:80 83.161.120.155:60184 CLOSE_WAIT tcp 391 0 83.161.120.155:80 83.161.120.155:3461 CLOSE_WAIT tcp 264 0 83.161.120.155:80 83.161.120.155:34452 CLOSE_WAIT tcp 348 0 83.161.120.155:80 83.161.120.155:2073 ESTABLISHED tcp 0 0 83.161.120.155:80 83.161.120.155:3462 ESTABLISHED tcp 385 0 83.161.120.155:80 83.161.120.155:3463 CLOSE_WAIT tcp 264 0 83.161.120.155:80 83.161.120.155:34554 CLOSE_WAIT tcp 0 124 83.161.120.155:23 83.161.120.155:3243 ESTABLISHED tcp 241 0 83.161.120.155:80 83.161.120.155:3471 ESTABLISHED tcp 342 0 83.161.120.155:80 83.161.120.155:6924 ESTABLISHED Also, please be aware of the fact that the problem seemed to have changed when we upgraded to the Redhat 5.2rpm version of Apache...... now, instead of crashing every 20-24 hours, it is not expiring all requests, and eventually will lock up all available processes... I'll try and include a copy or you can view it yourself at http://www.v6fbody.com/server-status Login:apache Password:group Thank you. Darrin Martin -------snip--------- Comment-Added-By: dgaudet Comment-Added-When: Tue Mar 16 08:34:26 PST 1999 Comment-Added: When the problem happens, do a "netstat -nt" -- that should show to where the ESTABLISHED port 80 connections are ... I suspect something is just holding connections open. If that doesn't help, use "strace" on a few of the children to see what they're doing: strace -p pid_of_child Dean From janetmason@example.net Sat May 01 17:52:13 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 9037 invoked by uid 6000); 1 May 1999 17:52:12 -0000 Received: (qmail 9003 invoked by uid 143); 1 May 1999 17:52:08 -0000 Date: 1 May 1999 17:52:08 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-linux/2774: Heavily loaded webserver stops accepting all connections after some time. Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Heavily loaded webserver stops accepting all connections after some time. Comment-Added-By: dgaudet Comment-Added-When: Sat May 1 10:51:54 PDT 1999 Comment-Added: Do you still have this problem with 1.3.6? We changed the default locking behaviour on linux back to the 1.2.x settings. Dean From janetmason@example.net Sat May 01 17:53:49 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 10343 invoked by uid 6000); 1 May 1999 17:53:49 -0000 Received: (qmail 10324 invoked by uid 143); 1 May 1999 17:53:47 -0000 Date: 1 May 1999 17:53:47 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-linux/3353: Server processes die, only one remains (root) Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Server processes die, only one remains (root) Comment-Added-By: dgaudet Comment-Added-When: Sat May 1 10:53:46 PDT 1999 Comment-Added: Is your problem still occuring? I'm still interested in getting an strace of the parent process when the problem occurs... it sounds like a kernel bug which we're trying to get more data on so that we can get the linux folks to fix it. Dean From janetmason@example.net Sat May 01 17:55:12 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 10874 invoked by uid 6000); 1 May 1999 17:55:10 -0000 Received: (qmail 10856 invoked by uid 143); 1 May 1999 17:55:09 -0000 Date: 1 May 1999 17:55:09 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-linux/3387: Regularly the httpd children will all die with no errors given, the root process will still be running, must stop and restart httpd. Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Regularly the httpd children will all die with no errors given, the root process will still be running, must stop and restart httpd. Comment-Added-By: dgaudet Comment-Added-When: Sat May 1 10:55:04 PDT 1999 Comment-Added: Is your problem still occuring? We're trying to track down more information on problems like this because we think it is a kernel bug. An strace of the parent process when this problem happens would be excellent... Dean From janetmason@example.net Sat May 01 17:56:52 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 11105 invoked by uid 6000); 1 May 1999 17:56:51 -0000 Received: (qmail 11085 invoked by uid 143); 1 May 1999 17:56:50 -0000 Date: 1 May 1999 17:56:50 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-linux/3897: 1.3.4 server starts, seemingly normally... dies, no children, no errors not the case with 1.2.0 Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: 1.3.4 server starts, seemingly normally... dies, no children, no errors not the case with 1.2.0 Comment-Added-By: dgaudet Comment-Added-When: Sat May 1 10:56:49 PDT 1999 Comment-Added: [This is a standard response.] This Apache problem report has not been updated recently. Please reply to this message if you have any additional information about this issue, or if you have answers to any questions that have been posed to you. If there are no outstanding questions, please consider this a request to try to reproduce the problem with the latest software release, if one has been made since last contact. If we don't hear from you, this report will be closed. If you have information to add, BE SURE to reply to this message and include the janetmason@example.net address so it will be attached to the problem report! From janetmason@example.net Sat May 01 20:12:46 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 27645 invoked by uid 6000); 1 May 1999 20:12:45 -0000 Received: (qmail 27623 invoked from network); 1 May 1999 20:12:43 -0000 Received: from ip68.boanxr5.ras.tele.dk (HELO tigger.tange.dk) (janetmason@example.net) by taz.hyperreal.org with SMTP; 1 May 1999 20:12:43 -0000 Received: from l (l [83.161.120.155]) by tigger.tange.dk (Postfix) with ESMTP id 737AF108092; Sat, 1 May 1999 22:12:38 +0200 (CEST) Date: Sat, 1 May 1999 22:12:38 +0200 (CEST) From: Ole Tange <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, janetmason@example.net Subject: Re: os-linux/3312: Children die. Parent stops serving requests In-Reply-To: <janetmason@example.net> Message-ID: <janetmason@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: janetmason@example.net Precedence: bulk On 1 May 1999 janetmason@example.net wrote: > Somehow 242 seconds passed between the two time() calls... the parent does > nothing cpu intensive, so I doubt it's that. It's possible the guy's box > is swapping to hell... but we've got about a dozen similar reports. Nope. In that case the load ought to rise, which it didnot. The problem was worked around by disabling keep-alives. > The reports are against 2.0.30, 2.0.32, and 2.0.33. After upgrading to kernel 2.0.36 and apache 1.3.4 I have been able to re-enable keepalives with no problems so far. > The short answer: kernel problem. Alan Cox hasn't heard of > this problem before, so it's probably an unknown problem. The short comment: Case appears solved by upgrading. /Ole From janetmason@example.net Sat May 01 20:20:02 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 29538 invoked by uid 6000); 1 May 1999 20:20:02 -0000 Received: (qmail 29526 invoked by uid 2001); 1 May 1999 20:20:00 -0000 Date: 1 May 1999 20:20:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Ole Tange <janetmason@example.net> Subject: Re: os-linux/3312: Children die. Parent stops serving requests Reply-To: Ole Tange <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR os-linux/3312; it has been noted by GNATS. From: Ole Tange <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, janetmason@example.net Subject: Re: os-linux/3312: Children die. Parent stops serving requests Date: Sat, 1 May 1999 22:12:38 +0200 (CEST) On 1 May 1999 janetmason@example.net wrote: > Somehow 242 seconds passed between the two time() calls... the parent does > nothing cpu intensive, so I doubt it's that. It's possible the guy's box > is swapping to hell... but we've got about a dozen similar reports. Nope. In that case the load ought to rise, which it didnot. The problem was worked around by disabling keep-alives. > The reports are against 2.0.30, 2.0.32, and 2.0.33. After upgrading to kernel 2.0.36 and apache 1.3.4 I have been able to re-enable keepalives with no problems so far. > The short answer: kernel problem. Alan Cox hasn't heard of > this problem before, so it's probably an unknown problem. The short comment: Case appears solved by upgrading. /Ole From janetmason@example.net Sat May 01 20:20:08 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 29605 invoked by uid 6000); 1 May 1999 20:20:07 -0000 Received: (qmail 29526 invoked by uid 2001); 1 May 1999 20:20:00 -0000 Date: 1 May 1999 20:20:00 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, From: Ole Tange <janetmason@example.net> Subject: Re: os-linux/3312: Children die. Parent stops serving requests Reply-To: Ole Tange <janetmason@example.net> Sender: janetmason@example.net Precedence: bulk The following reply was made to PR os-linux/3312; it has been noted by GNATS. From: Ole Tange <janetmason@example.net> To: janetmason@example.net Cc: janetmason@example.net, janetmason@example.net Subject: Re: os-linux/3312: Children die. Parent stops serving requests Date: Sat, 1 May 1999 22:12:38 +0200 (CEST) On 1 May 1999 janetmason@example.net wrote: > Somehow 242 seconds passed between the two time() calls... the parent does > nothing cpu intensive, so I doubt it's that. It's possible the guy's box > is swapping to hell... but we've got about a dozen similar reports. Nope. In that case the load ought to rise, which it didnot. The problem was worked around by disabling keep-alives. > The reports are against 2.0.30, 2.0.32, and 2.0.33. After upgrading to kernel 2.0.36 and apache 1.3.4 I have been able to re-enable keepalives with no problems so far. > The short answer: kernel problem. Alan Cox hasn't heard of > this problem before, so it's probably an unknown problem. The short comment: Case appears solved by upgrading. /Ole From janetmason@example.net Sat May 01 22:52:33 1999 Return-Path: <janetmason@example.net> Delivered-To: janetmason@example.net Received: (qmail 14080 invoked by uid 6000); 1 May 1999 22:52:32 -0000 Received: (qmail 14062 invoked by uid 212); 1 May 1999 22:52:31 -0000 Date: 1 May 1999 22:52:31 -0000 Message-ID: <janetmason@example.net> To: janetmason@example.net, janetmason@example.net, janetmason@example.net From: janetmason@example.net Subject: Re: os-solaris/3848: mod_perl won't compile on Solaris 2.5 Sender: janetmason@example.net Precedence: bulk [In order for any reply to be added to the PR database, ] [you need to include <janetmason@example.net> in the Cc line ] [and leave the subject line UNCHANGED. This is
{'source': 'Apache Software Foundation Public Mail Archives'}