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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
