tomcat hangs on startup if ssl is enabled

Bug #287644 reported by Craig on 2008-10-22
Affects Status Importance Assigned to Milestone
tomcat-native (Gentoo Linux)
tomcat-native (Ubuntu)

Bug Description

Just installed tomcat6, then start it up. It works fine.

Now install libtcnative-1, and restart tomcat. It won't start, and in the catalina log, you'll see:
Oct 22, 2008 12:27:22 PM org.apache.catalina.core.AprLifecycleListener init
INFO: Loaded APR based Apache Tomcat Native library 1.1.12.
Oct 22, 2008 12:27:22 PM org.apache.catalina.core.AprLifecycleListener init
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].

And that's it. Tomcat isn't listening on any ports, and nothing else happens.

According to the problem is that /dev/random is used for entropy, so Tomcat takes effectively forever to start with SSL enabled.

I confirmed this by disabling SSL in server.xml, and tomcat will start up. It seems that /dev/urandom must be used.

Changed in tomcat-native:
status: Unknown → Invalid
Andy Brook (javahollic) wrote :

same for me. Identical results when building with 1.1.19 source. not sure how the linked description helps Ubuntu. I happen to have ipv6 blacklisted, doesn't seem to help.

John Neffenger (jgneff) wrote :

I got rid of the hang (or very long delay) by changing this line in "conf/server.xml":

    <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />

to this:

    <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="off" />

but then I ran right into this error in the log file:

    25-Nov-2008 9:15:58 AM org.apache.catalina.core.AprLifecycleListener init
    INFO: Loaded APR based Apache Tomcat Native library 1.1.12.
    25-Nov-2008 9:15:58 AM org.apache.catalina.core.AprLifecycleListener init
    INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].
    25-Nov-2008 9:15:59 AM org.apache.coyote.http11.Http11AprProtocol init
    SEVERE: Error initializing endpoint
    java.lang.Exception: Socket bind failed: [22] Invalid argument

which apparently involves the IPv6 networking support and has been fixed by Apache:

    Socket bind fails on tomcat startup when using apr

There's a work-around for that, which I haven't tried, of removing IPv6 support in "/etc/modprobe.d/aliases", but I think I'll just uninstall "libtcnative-1" and wait. I was hoping APR would speed up Tomcat's startup time (perhaps with native random number generation?), but it seems to be about the same.

Craig (candrews-integralblue) wrote :

The IPv6 issue has been reported in bug 287645.

Upgrading tomcat-native to 1.1.15 should fix both the ipv6 and ssl issues. A bump request is in bug 290078

I've similar issue on Ubuntu, but im my case, as you can see from log, jboss hangs only for about 1 minute. Then it still loading.

22:02:40,026 INFO [AprLifecycleListener] Loaded Apache Tomcat Native library 1.1.16.
22:02:40,026 INFO [AprLifecycleListener] APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].
22:04:09,467 INFO [Http11AprProtocol] Initializing Coyote HTTP/1.1 on http-

John Anderson (john-e-anderson) wrote :

Still seeing this issue in karmic with version 1.1.16

nuscly (nuscly) wrote :

To disable random that lock tomcat, I disable it in APR.

If you compile by yourself APR, you can fix it like it :

cd apache-tomcat-6.0.29/tomcat-native-1.1.20-src/jni/native/
In include/tcn.h
I Add the line 33 #undef APR_HAS_RANDOM

Then when you start : APR capabilities ... random [false]

Changed in tomcat-native (Gentoo Linux):
importance: Unknown → Medium

doesn this still happen with tomcat native 1.1.29? and tomcat .49

Andreas Ntaflos (daff) wrote :

A possible workaround for this problem is to install an entropy gathering daemon like haveged (apt-get install haveged) to keep /dev/random supplied with entropy. Requires no additional configuration and speeds things up tremendously.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.