DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=41828>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41828 Summary: mod_jk file locking (flock) causes kernel panic Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We have encountered several kernel panics in our benchmark tests using Apache bench (ab). Test environments are: RedHat Enterprise Linux 4.0 update 4 Apache 2.0.52 mod_jk 1.2.20 Tomcat 5.5.17 It turned out to be a kernel bug (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230976), and we also found that mod_jk file locking problem in jk_shm.c is a main cause of the kernel panic. First, Apache mod_jk parent process opens shared memory file "jk-runtime-status" and its lock file "jk-runtime-status.lock". Next, forked child processes inherit the parent data including file descriptors (fd) of these files. The child processes don't re-open these files. It then results that all mod_jk processes are locking/unlocking the same file with same fd. The problem is that flock system call with LOCK_EX (exclusive lock) from a process (A) has no effect if another process (B) has already locked the same file with same fd. The flock does not block process A and returns without an error. This is how flock works. And if process (A) calls flock with LOCK_UN (unlock) to the file, the file is unlocked even if process (B) is locking the file, which is a main cause of the kernel panic. The child process should re-open the lock file and use a new fd for flock system call, in order to lock a file strictly. I have verified that the following code fragments which re-opens a lock file for child processes has some effect and does not cause a kernel panic. jk_shm.c:do_shm_open if (jk_shmem.hdr) { /* Probably a call from vhost */ if (JK_IS_DEBUG_LEVEL(l)) jk_log(l, JK_LOG_DEBUG, "Shared memory is already open"); /* start of temporary code */ if( attached ) { if ((rc = do_shm_open_lock(fname, attached, l))) { munmap((void *)jk_shmem.hdr, jk_shmem.size); close(jk_shmem.fd); jk_shmem.hdr = NULL; jk_shmem.fd = -1; JK_TRACE_EXIT(l); return rc; } } /* end of temporary code */ return 0; } In such situation, we are afraid that the shared memory is not safe among multi-processes or multi-threads. Thank you for your help. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
