Received: (qmail 14764 invoked by uid 2012); 19 Mar 1999 22:45:31 -0000 Message-Id: <19990319224531.14763.qmail@hyperreal.org> Date: 19 Mar 1999 22:45:31 -0000 From: Larry Glaze Reply-To: lglaze@iddg.com To: apbugs@hyperreal.org Subject: The web server stops responding to client requests although it remains running. X-Send-Pr-Version: 3.2 >Number: 4093 >Category: os-solaris >Synopsis: The web server stops responding to client requests although it remains running. >Confidential: no >Severity: critical >Priority: medium >Responsible: apache >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Fri Mar 19 14:50:02 PST 1999 >Closed-Date: Mon Oct 30 19:07:27 PST 2000 >Last-Modified: Mon Oct 30 19:07:27 PST 2000 >Originator: lglaze@iddg.com >Release: 1.3.4 >Organization: >Environment: uname -a: SunOS ultra73 5.6 Generic_105181-11 sun4u sparc SUNW,Ultra-5_10 OS: Solaris 2.6 Compiler: gcc version 2.8.1 >Description: Apache stops responding to client requests. It remains running, however, but gives absolutely no errors in either its own error_log or in the server syslog. Apache usually has about 150 processes running when responding properly. When it stops responding, the number of processes will drop down to 40 or so. My guess is that apache thinks it is idle now and starts killing off some of its child processes. This problem existed before we compiled in mod_perl. The version of mod_perl we are using is 1.18. Everything besides this version of mod_perl came with the apache source. I have seen a couple other people mention this bug but haven't seen any responses about a possible fix. For now I have to run a monitoring script which will restart apache when it stops responding. Here is the output of "httpd -v" and "httpd -l": httpd -v: Server version: Apache/1.3.4 (Unix) Server built: Mar 4 1999 23:02:34 httpd -l: Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_access.c mod_auth.c mod_setenvif.c mod_perl.c >How-To-Repeat: Unsure. It happens randomly. >Fix: No. >Release-Note: >Audit-Trail: State-Changed-From-To: open-feedback State-Changed-By: dgaudet State-Changed-When: Tue Apr 20 13:46:07 PDT 1999 State-Changed-Why: Yeah this is in the database a few times... and until someone gives us data from which we can debug it there probably won't be a fix. Just like I asked the other folks, could you provide truss output for the parent and children when it is frozen. Other questions: - do you use NFS? - do you have enough swap space? use swap -s to check thanks Dean Comment-Added-By: coar Comment-Added-When: Wed Jun 7 14:16:31 PDT 2000 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 apbugs@Apache.Org address so it will be attached to the problem report! State-Changed-From-To: feedback-closed State-Changed-By: slive State-Changed-When: Mon Oct 30 19:07:26 PST 2000 State-Changed-Why: [This is a standard response.] No response from submitter, assuming issue has been resolved. >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include 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! ]