I'm using mod_jk2 2.0.4. jk_logger_file.c uses apr_file_open_stderr to create a stderr handle. jk2_logger_file_init is called twice - once from setProperty, and once from jk2_workerEnv_init. on the second call, the previously created stderr handle is closed, and another apr_file_t handle is created - on the already closed file handle 2. nothing is logged from now on, EBADF. (there is no separate bugzilla product for tomcat-connectors, so I put this report into Tomcat 5/Native:JK, no idea if this is correct)
This is an OK place to put the bug. So we should modify the jk2_workerEnv_init method so that if it already has a handle on stderr, it won't close and reopen? Why doesn't it work actually, after all the second stderr handle should still be valid, no? If you have an actual patch to jk_logger_file.c it'd be welcome.
Explanation: apr_file_open_stderr does not dup() the system stderr filehandle (fd 2), it just creates a new APR wrapper for fd 2. If you close the APR handle, the original system stderr is closed, and all APR wrappers for fd 2 become invalid. This might be considered an APR bug, because the abstraction offered by APR is not consistent here. I'll attach my solution later today when I'm at my office.
Created attachment 11708 [details] workaround patch (untested)
I have now attached a patch which works around the problem - it tests whether the previous name was "stderr" and simply doesn't close stderr handles. I just wrote down that patch without testing... just an idea to start with. Previously, I have commented out the apr_file_close line in jk2_logger_file_init. Object destruction and freeing memory doesn't really work in jk2 anyways (ever tried to run a small JK2 test program with dmalloc or similar heap debuggers? For some classes, there aren't even destructors available.. - email me if you want my help with the code cleanup required here)
OK, patch applied to file.