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 ------- Additional Comments From [EMAIL PROTECTED] 2003-11-18 18:04 ------- Today, I wanted to make a fresh start at investigating this problem. In doing so, started with a clean set of mod_jk 1.2.5 sources, then added in a few extra logging statements, similar to the ones that generated http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=8971 However, this time, I used syslog(2) for all of the additional logging. Now I see where the leak is: Nov 18 12:42:14 yacht httpd[23079]: jk_open_file_logger:../common/jk_util.c:201: opened logger=ba3c8 to file=/d/apache-1.3.28-200308/logs/localhost/two_mod_jk_log with FILE=ad4d8 and fileno=9 Nov 18 12:42:14 yacht httpd[23079]: jk_open_file_logger:../common/jk_util.c:201: opened logger=ec900 to file=/d/apache-1.3.28-200308/logs/localhost/one_mod_jk_log with FILE=ad4e8 and fileno=10 Nov 18 12:42:19 yacht httpd[23090]: jk_close_file_logger../common/jk_util.c:224: closing logger=ba3c8 with FILE=ad4d8 and fileno=9 Nov 18 12:42:19 yacht httpd[23090]: jk_close_file_logger../common/jk_util.c:224: closing logger=ec900 with FILE=ad4e8 and fileno=10 The bracketed number after httpd is the process PID. The logs are opened by PID 23079, which is the parent apache process. That's where the fopens() happen. The fcloses() on the other hand, are happening in the the _child_ httpd processes (!= 23079); they're balanced, but opens and closes are taking place in different processes. I will attach a larger excerpt where the following takes place: - start httpd - send a series of SIGHUPs, several seconds apart With each HUP, two files are opened by 23079, and two files are closed by a child process (!= 23079). I'm not sure what the best way to fix this would be. Perhaps opening the logfiles in a child init function? Or maybe ap_register_cleanup? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
