Bug 178483 - FC4 kernel horks tomcat (similar to LD_ASSUME_KERNEL)
FC4 kernel horks tomcat (similar to LD_ASSUME_KERNEL)
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-20 16:58 EST by Chris Abajian
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-27 19:05:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Abajian 2006-01-20 16:58:38 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Description of problem:
FC4's kernel is creating problems with tomcat (java) similar to those for which the LD_ASSUME_KERNEL env var fix was added to tomcat.

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 tomcat release
notes.  It changes the behavior slightly, but the problem remains (more
below).

Why I think this is a kernel problem:
It's NOT reproducible using same JDK and tomcat versions on Fedora 3 install.




Version-Release number of selected component (if applicable):
kernel-smp-2.6.14-1.1656_FC4

How reproducible:
Always

Steps to Reproduce:
1) run startup.sh
2) hit localhost:8080 in browser, works
3) run shutdown.sh

  

Actual Results:  Tomcat hangs for 2-3 minutes, leaves thread listening to socket, then dies with severe error.

Expected Results:  Tomcat shuts down normally.

Additional info:

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. 

This problem does not occur on the box sitting next to it with an FC3 install:

same java:
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)

same tomcat: Apache Tomcat/5.5.12

different kernel:
Linux 2.6.12-1.1381_FC3

different glibc.  this box works:

$ rpm -qa | grep -i libc
libcap-1.10-20
glibc-2.3.5-0.fc3.1
glibc-devel-2.3.5-0.fc3.1
libcap-devel-1.10-20
glibc-kernheaders-2.4-9.1.87
glibc-common-2.3.5-0.fc3.1
glibc-headers-2.3.5-0.fc3.1

this box doesn't work:

$ rpm -qa | grep -i libc
glibc-common-2.3.5-10.3
libcroco-0.6.0-5
libcap-devel-1.10-22
libcroco-devel-0.6.0-5
glibc-2.3.5-10.3
glibc-devel-2.3.5-10.3
glibc-kernheaders-2.4-9.1.94
glibc-2.3.5-10
libcap-1.10-22
glibc-headers-2.3.5-10.3

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
Comment 1 Chris Abajian 2006-01-27 19:05:54 EST
Installed Debian Sarge distro.  Fixed this and several other problems.

Note You need to log in before you can comment on or make changes to this bug.