Re: os-linux/3343: Server dies after 1-20 hours of usage.

1999-02-22 Thread Mark Herman II
The following reply was made to PR os-linux/3343; it has been noted by GNATS.

From: Mark Herman II [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage.
Date: Sun, 21 Feb 1999 18:40:47 -0600

 [EMAIL PROTECTED] wrote:
 
  [In order for any reply to be added to the PR database, ]
  [you need to include [EMAIL PROTECTED] 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.
 
  Comment-Added-By: lars
  Comment-Added-When: Thu Feb 11 12:51:43 PST 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 [EMAIL PROTECTED] address so it
  will be attached to the problem report!
 
 Hi,
 The server still dies, but we did find something that may be
 contributing to it.  We just are not sure why.  He runs a mailbag script
 that mails the traffic of his bulletin board to its subscribers every
 hour.  If he disables this script, the web server doesn't die.  We
 haven't found anything in this script that we believe would kill the web
 server, but if you would like to see it, I can forward it to you.
 
 Mark
 
 


Re: os-linux/3343: Server dies after 1-20 hours of usage.

1998-11-05 Thread Mark Herman II
The following reply was made to PR os-linux/3343; it has been noted by GNATS.

From: Mark Herman II [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage.
Date: Thu, 05 Nov 1998 00:14:10 -0600

 Hi,
 Thanks for the quick reply.  Here are the settings you asked for:
 
 MaxRequestsPerChild is set to 64.  It was set to 30, but I increased
 it.  This seemed to make the server take longer to die.
 
 MaxClients is set to 150
 
 MinSpareServers is 5
 
 MaxSpareServers is 10
 
 BTW, we are running a custom transfer log, but we weren't when the
 problem started.  I noticed another message in the database regarding
 custom logs, but this shouldn't be the cause of the problem.
 
 There were no unusual messages in the error log file.  I also checked
 the syslog messages file, and I did notice several messages about
 possible SYN floods, but the times don't appear to correspond with the
 unresponsiveness of httpd.
 
 Thanks
 
 [EMAIL PROTECTED] wrote:
 
  [In order for any reply to be added to the PR database, ]
  [you need to include [EMAIL PROTECTED] 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: open-feedback
  State-Changed-By: lars
  State-Changed-When: Wed Nov  4 18:30:46 PST 1998
  State-Changed-Why:
 
  Are there any messages in your error log?
 
  What are your MaxClients, MaxRequestsPerChild
  and Min/MaxSpareServers settings?
 
  Release-Changed-From-To: 1.2.6 and 1.3.3-1.3.3
  Release-Changed-By: lars
  Release-Changed-When: Wed Nov  4 18:30:46 PST 1998
 


os-linux/3343: Server dies after 1-20 hours of usage.

1998-11-04 Thread Mark Herman II

Number: 3343
Category:   os-linux
Synopsis:   Server dies after 1-20 hours of usage.
Confidential:   no
Severity:   critical
Priority:   medium
Responsible:apache
State:  open
Class:  sw-bug
Submitter-Id:   apache
Arrival-Date:   Wed Nov  4 14:40:00 PST 1998
Last-Modified:
Originator: [EMAIL PROTECTED]
Organization:
apache
Release:1.2.6 and 1.3.3
Environment:
Red Hat Linux with kernel version 2.0.35.  It has been patched to glibc2.0.7.
I am using gcc2.7.2.3, but the 1.2.6 server we were using
came with Red Hat Linux.

Description:
There is no core dump.  The server-status report from the 1.2.6 apache server 
would
show processes marked as running although they no longer existed.  Once it 
reached the
maximum number of requests for a child, it would kill the child, but it would 
still
appear as running in the server-status report.  It would then start a new 
process, since it can't use the dead
ones.  After several hours it would reach the maximum number of processes and 
stop
answering requests.

The 1.3.3 version does not exibit the same behavior in the server status 
report, but
it still dies.

How-To-Repeat:
I don't know what is causing it, so I can't repeat it.
You can access the server-status report at the following URL:

http://www.v6fbody.com/server-status/

The username and password are:
username: apache
password: group

The website address is http://www.v6fbody.com/
Fix:
We started a cron job to restart the server on a periodic basis.
Audit-Trail:
Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include [EMAIL PROTECTED] 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! ]





protocol/875: force-response-1.0 bug

1997-07-16 Thread Mark Herman II

Number: 875
Category:   protocol
Synopsis:   force-response-1.0 bug
Confidential:   no
Severity:   serious
Priority:   medium
Responsible:apache (Apache HTTP Project)
State:  open
Class:  sw-bug
Submitter-Id:   apache
Arrival-Date:   Wed Jul 16 12:50:01 1997
Originator: [EMAIL PROTECTED]
Organization:
apache
Release:1.2.X
Environment:
BSDI 3.0.  I believe it will occur on any OS.  I also experience it on Linux.
Description:
I run the JCount Java access counter at http://www.jcount.com/.  We included
the BrowserMatch lines that were suggested in the FAQ.  This counter works
properly on all browsers I've tried except Internet Explorer 4.0 Preview Release
2.  The BrowserMatch lines tell the server to send back HTTP/1.0 response
headers to IE 4.0 PR 2.  While searching for the cause of this error, I tried
telnetting directly into the server and typing the http requests myself.  I've
found that using the force-response-1.0 directive sends back the HTTP/1.0 
header, but
HTTP/1.1 encoded information.  The specific problem that this is causing me is
that if I call my CGI scripts in IE 4.0 PR 2, it has an extra number before the
beginning of my program's output.  It would seem that any Java applet that uses
CGI to communicate with a server runs a chance of running into this problem on
this browser.  I think I will find a simple fix in my particular case, but I
still think this should be addressed.
How-To-Repeat:
telnet into www.jcount.com port 80, and type the following:
GET /cgi-bin/counter2.cgi?secondary_exposure=trueincrement=falsecounter_id=30 
HTTP/1.1
Host: www.jcount.com

I have set the force-response-1.0 environment variable to help find the problem.
I will be setting this back to normal soon, but for now, the output will be:

HTTP/1.0 200 OK
Then what appears to be a HTTP/1.1 header will follow.  After that, there will 
be
a blank line, then some hexadecimal number, which is the cause of my problems.
In my case, my program parses the output based on which line it is on.
I am assuming that this new number has something to do with the HTTP/1.1 
response,
because it doesn't show up if I request the information using HTTP/1.0.
Fix:
Instead of having the force-response-1.0 directive just change the first line
of the header sent back, send back a true HTTP/1.0 response
Audit-Trail:
Unformatted: