Re: Apache 1.3.28/mod_jk-1.2.5/Solaris - fd leak?

[srevilak]

> From: Christopher Schultz

> It sounds like mod_jk doesn't handle the "restart" notification from
> Apache very well. It's also possible that mod_jk doesn't attempt to
> close any open streams when the log file name is changed (which is
> likely to happen when Apache reloads its config). The name will be
> the same, but there's still a message sent to the module that some
> configuration changed. I suppose this is the same thing as "not
> handling restart notification properly".

Thanks for the feedback, Chris.  I've been digging through mod_jk's
source code; it does set a cleanup handler (exit_handler()) in it's
module struct, and mod_jk.c:exit_handler() looks like it's going
through a bit of trouble to close logfiles.  Adding a few
ap_log_error() calls to exit_handler, I can see that there are closes
taking place.

Beyond that, I'm can't say very much without straying into the
hypothetical.  At least not yet :(


> Have you tried jk2?

No, I haven't tried mod_jk2.  The impression I've always had was that
mod_jk better suited for Apache 1.3.x, and mod_jk2 was better suited
for Apache 2.0.x.  That was the main criteria that I used.

I have seen other posters using jk; it doesn't seem unreasonable to
think that others might be affected by this leaking file descriptor
phenemenon.  That's one of my motivations in wanting to get to the
bottom of it.

Thanks.

-- 
Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Apache 1.3.28/mod_jk-1.2.5/Solaris - fd leak?

[Christopher Schultz]

> After the HUP, there are two additional file descriptors open.
> Another HUP will open up two more, and so forth.  USR1 (aka apachectl
> graceful) seems to produce similar results.
It sounds like mod_jk doesn't handle the "restart" notification from 
Apache very well. It's also possible that mod_jk doesn't attempt to 
close any open streams when the log file name is changed (which is 
likely to happen when Apache reloads its config). The name will be the 
same, but there's still a message sent to the module that some 
configuration changed. I suppose this is the same thing as "not handling 
restart notification properly".

Have you tried jk2? Everyone on this list seems to indicate that moving 
to jk2 is a good idea in general.

-chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Apache 1.3.28/mod_jk-1.2.5/Solaris - fd leak?

[srevilak]

Hi all.

I have a tomcat setup that works through mod_jk-1.2.5 and Apache
1.3.28, running on Solaris 7 and Solaris 8 boxes.  I've found what
appears to be a file descriptor leak.  I haven't been able to find
mention of this on http://marc.theaimsgroup.com/?l=tomcat-user, or in
apache's bug reporting database.

I was hoping to see whether anyone else had seen similar behavior,
or if anyone else could reproduce it.

After a cold start, this is what the list of open fd's looks like.
"one_mod_jk_log" and "two_mod_jk_log" are files named by JkLogFile
directives (there are two JkLogfile directives, each in a different
VirtualHost container in srm.conf).

  $ 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 root4u  VREG 136,0 3023 848146 
/l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root5u  VREG 136,0 3023 848147 
/l/apache/logs/localhost/one_mod_jk_log
  httpd   21307 root6u  VREG 136,0 3023 848146 
/l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root7u  VREG 136,0 3023 848147 
/l/apache/logs/localhost/one_mod_jk_log

After signaling the server to restart, the number of open descriptors
increases.  (/etc/httpd.pid is Apache's PidFile).

  $ 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 root4u  VREG 136,0 5028 848146 
/l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root5u  VREG 136,0 5029 848147 
/l/apache/logs/localhost/one_mod_jk_log
  httpd   21307 root6u  VREG 136,0 5028 848146 
/l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root7u  VREG 136,0 5029 848147 
/l/apache/logs/localhost/one_mod_jk_log
  httpd   21307 root8u  VREG 136,0 5028 848146 
/l/apache/logs/localhost/two_mod_jk_log
  httpd   21307 root9u  VREG 136,0 5029 848147 
/l/apache/logs/localhost/one_mod_jk_log

After the HUP, there are two additional file descriptors open.
Another HUP will open up two more, and so forth.  USR1 (aka apachectl
graceful) seems to produce similar results.

The problem really shows itself with log rotations; you need to
restart the server in order to have it close and reopen its logfiles.
But in this case, the parent httpd process eventually runs out of file
descriptors and dies. :(

mod_jk-1.2.3 shows the same behavior.

If any of the other mod_jk/apache users wouldn't mind trying to
reproduce this, I'd very much appreciate knowing what you found.
Likewise, if anyone could offer a pointer to a workaround.

Thanks in advance.

-- 
Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]