DO NOT REPLY [Bug 24462] New: - mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462

mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1

           Summary: mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on
                    SIGHUP/SIGUSR1
           Product: Tomcat 4
           Version: 4.1.27
          Platform: Sun
        OS/Version: Solaris
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Connector:Other
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: srevilak@g88.net


I'm would like to report a file descriptor leak that occurs with
Apache-1.3.28 and mod_jk-1.2.5 on Solaris 7 and Solaris 8.  Both
Apache and mod_jk were compiled from sources.  mod_jk is being used as
DSO (not statically linked).

The problem appears when apache is restarted via SIGHUP (aka
"apachectl restart") SIGUSR1 ("apachectl graceful").

Each time the server is signaled, the parent server process will have
open one additional file descriptor for each file given in a JkLogFile
directive.

Below is a short series of annotated lsof output that shows the
behavior.  For this, two JkLogFile directives are use; each in a
different VirtualHost container element.  (However, the same behavior
also exists when JkLogFile is used at the server config level, outside
of any container elements).

##
## lsof output after a cold start of Apache, filtered to include only
## files matching "_jk". "/etc/httpd.pid" is the file named by the
## servers PidFile directive.
##
## logs/localhost/one_mod_jk_log and logs/localhost/two_mod_jk_log
## are the files named by JkLogFile.  JkLogFile appears twice in 
## the server configuration.  No requests have been made to the server.
##
  $ lsof -p `cat /etc/httpd.pid ` | grep _jk
  COMMAND     PID     USER   FD   TYPE        DEVICE  SIZE/OFF     NODE NAME
  httpd   21307 root  txt   VREG         136,0   834728 
958215 /l/apache/libexec/mod_jk.so
  httpd   21307 root    4u  VREG         136,0     3023 
848146 /l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root    5u  VREG         136,0     3023 
848147 /l/apache/logs/localhost/one_mod_jk_log
  httpd   21307 root    6u  VREG         136,0     3023 
848146 /l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root    7u  VREG         136,0     3023 
848147 /l/apache/logs/localhost/one_mod_jk_log

##
## SIGHUP server; then another snapshot of files containing "_jk".
## Below, where two descriptors were open to "one_mod_jk_log", there
## are now three.  Likewise, where there were two descriptors open
## to "two_mod_jk_log" there are also three.
##
  $ kill -HUP `cat /etc/httpd.pid `
  $ lsof -p `cat /etc/httpd.pid ` | grep _jk
  httpd   21307 root  txt   VREG         136,0   834728 
958215 /l/apache/libexec/mod_jk.so
  httpd   21307 root    4u  VREG         136,0     5028 
848146 /l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root    5u  VREG         136,0     5029 
848147 /l/apache/logs/localhost/one_mod_jk_log
  httpd   21307 root    6u  VREG         136,0     5028 
848146 /l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root    7u  VREG         136,0     5029 
848147 /l/apache/logs/localhost/one_mod_jk_log
  httpd   21307 root    8u  VREG         136,0     5028 
848146 /l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root    9u  VREG         136,0     5029 
848147 /l/apache/logs/localhost/one_mod_jk_log

A subsequence SIGHUP (or SIGUSR1) will result in allocation of one
more file descriptor per each file named by JkLogFile.  (i.e. - the
more times JkLogFile is used, the faster it leaks).

Eventually, successive SIGHUPs will exhaust the number of descriptors
available to the server, causing it to crash.  In my particular case,
this would occur during nightly log rotations.

A few days ago, I brought this issue up on the tomcat-users mailing
list:

  http://marc.theaimsgroup.com/?t=106797123900012&r=1&w=2

However, none of the respondents indicated whether they had, or had
not observed this behavior in their own installations.

Finally, mod_jk-1.2.3 also exhibits the same behavior.

If there's additional information needed, I would be happy to provide
it.  Likewise, if I could assist the maintainers by performing some
additional testing, I would be more than happy to do so.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org