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=38335>. 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=38335 Summary: Tomcat fails to shut down in response to shutdown.sh script Product: Tomcat 5 Version: 5.5.12 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat fails to shut down in response to shutdown.sh script. Hangs, eventually throws exception with dreaded "Protocol handler pause failed" message. I have tried both values for LD_ASSUME_KERNEL as per release notes. It changes the behavior slightly, but the problem remains (more below). Environment: - A freshly built & updated fedora RC4 install: 2.6.14-1.1656_FC4 - A completely unmodified Tomcat Version 5.5.12 - I untarred it and ran it. - Sun's jdk1.5.0_06 Repro: 1) run startup.sh 2) hit localhost:8080 in browser, works 3) run shutdown.sh 4) log shows: Jan 19, 2006 11:08:27 PM org.apache.coyote.http11.Http11BaseProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 It hangs for a minute or so, then throws: Jan 19, 2006 11:03:48 PM org.apache.catalina.connector.Connector pause SEVERE: Protocol handler pause failed java.net.ConnectException: Connection timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:507) at java.net.Socket.connect(Socket.java:457) at java.net.Socket.<init>(Socket.java:365) at java.net.Socket.<init>(Socket.java:207) at org.apache.jk.common.ChannelSocket.unLockSocket(ChannelSocket.java:463) at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:270) at org.apache.jk.server.JkMain.pause(JkMain.java:679) at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:162) at org.apache.catalina.connector.Connector.pause(Connector.java:1031) at org.apache.catalina.core.StandardService.stop(StandardService.java:491) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:714) at org.apache.catalina.startup.Catalina.stop(Catalina.java:586) at org.apache.catalina.startup.Catalina.start(Catalina.java:561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Interestingly enough, lsof shows different behaviors depending on the value of the LD_ASSSUME_KERNEL variable. With no variable set, # lsof -P | grep java | grep 8080 java 6555 chris 10u IPv6 329120 TCP *:8080 (LISTEN) setting LD_ASSUME_KERNEL=2.2.5 results in about 40 threads listening on the port (in the hung state): # lsof -P | grep java | grep 8080 java 6652 chris 12u IPv6 331547 TCP *:8080 (LISTEN) java 6653 chris 12u IPv6 331547 TCP *:8080 (LISTEN) ...etc setting it to 2.4.1 yields the more entertaining: # lsof -P | grep java | grep 8080 java 6779 chris mem REG 253,0 1465636 4980808 /lib/obsolete/linuxthreads/i686/libc-2.3.5.so java 6779 chris 12u IPv6 334251 TCP *:8080 (LISTEN) java 6780 chris mem REG 253,0 1465636 4980808 /lib/obsolete/linuxthreads/i686/libc-2.3.5.so java 6780 chris 12u IPv6 334251 TCP *:8080 (LISTEN) ... but the behavior is the same. Surely tomcat on Fedora can't be this broken out of the box, can it? -- 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]
