Tomcat7 starts too late on Ubuntu 14.04 x64 [Digitalocean]

i am using digitalocean and trying to install and start tomcat on ubuntu but unfortunately i can not do it. (created new droplets and tried 10 times)

1GB Ram 30GB SSD Disk Amsterdam 2 Ubuntu 14.04 x64

When i start tomcat, it says "Tomcat started". But i can not access page from browser. and ./shutdown.sh returns error.

What can be the problem ?

I noticed something now. While i am writing this question, tomcat page is displayed. it took 28 minutes to display the page

catalina.out says: INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [1,718,769] milliseconds.

Here are my installation steps (These steps works on different vps but doesn't work on digitalocean droplets):

Install oracle jdk

 sudo apt-get install python-software-properties
 sudo add-apt-repository ppa:webupd8team/java
 sudo apt-get update
 sudo apt-get install oracle-java7-installer
 sudo apt-get install oracle-java7-set-default
      java -version
      java version "1.7.0_72"
      Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
      Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)

Set java path

      sudo nano /etc/environment
      JAVA_HOME="/usr/lib/jvm/java-7-oracle"
      source /etc/environment
      wget http://ftp.itu.edu.tr/Mirror/Apache/tomcat/tomcat-7/v7.0.56/bin/apache-tomcat-7.0.56.tar.gz
      tar xvzf apache-tomcat-7.0.56.tar.gz
      mv apache-tomcat-7.0.56/ apache-tomcat-7.0.56-server-1/

Start Tomcat

		./startup.sh
			Using CATALINA_BASE:   /usr/local/apache-tomcat-7.0.56-server-1
			Using CATALINA_HOME:   /usr/local/apache-tomcat-7.0.56-server-1
			Using CATALINA_TMPDIR: /usr/local/apache-tomcat-7.0.56-server-1/temp
			Using JRE_HOME:        /usr/lib/jvm/java-7-oracle/jre
			Using CLASSPATH:       /usr/local/apache-tomcat-7.0.56-server-1/bin/bootstrap.jar:/usr/local/apache-tomcat-7.0.56-server-1/bin/tomcat-juli.jar
			Tomcat started.

Checkout Port 8080

		netstat -ln	
			tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
			tcp6       0      0 :::8009                 :::*                    LISTEN
			tcp6       0      0 :::8080                 :::*                    LISTEN
			tcp6       0      0 :::22                   :::*                    LISTEN

Checkout process

            ps -ef | grep tomcat
			root      2825     1  1 14:23 pts/0    00:00:03 /usr/lib/jvm/java-7-oracle/jre/bin/java -Djava.util.logging.config.file=/usr/local/apache-tomcat-7.0.56-server-1/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/apache-tomcat-7.0.56-server-1/endorsed -classpath /usr/local/apache-tomcat-7.0.56-server-1/bin/bootstrap.jar:/usr/local/apache-tomcat-7.0.56-server-1/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/apache-tomcat-7.0.56-server-1 -Dcatalina.home=/usr/local/apache-tomcat-7.0.56-server-1 -Djava.io.tmpdir=/usr/local/apache-tomcat-7.0.56-server-1/temp org.apache.catalina.startup.Bootstrap start

Open web site at port 8080 http://5.101.107.56:8080/ Page is waiting... [content is displayed after 28 minute or more]

Try to shutdown tomcat if content is not displayed yet (before tomcat starts properly).

      ./shutdown.sh 
			SEVERE: Could not contact localhost:8005. Tomcat may not be running.
			Oct 17, 2014 2:40:29 PM org.apache.catalina.startup.Catalina stopServer
			SEVERE: Catalina.stop:
				java.net.ConnectException: Connection refused
				at java.net.PlainSocketImpl.socketConnect(Native Method)
				at java.net.AbstractPlainSoc

Checkout logs

      catalina.out
			Oct 17, 2014 2:31:47 PM org.apache.coyote.AbstractProtocol init
			INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
			Oct 17, 2014 2:31:47 PM org.apache.catalina.startup.Catalina load
			INFO: Initialization processed in 1492 ms
			Oct 17, 2014 2:31:47 PM org.apache.catalina.core.StandardService startInternal
			INFO: Starting service Catalina
			Oct 17, 2014 2:31:47 PM org.apache.catalina.core.StandardEngine startInternal
			INFO: Starting Servlet Engine: Apache Tomcat/7.0.56
			Oct 17, 2014 2:31:47 PM org.apache.catalina.startup.HostConfig deployDirectory
			INFO: Deploying web application directory /usr/local/apache-tomcat-7.0.56-server-1/webapps/host-manager

I also installed nginx and navigate to http://5.XXX.XXX.XX/ nginx welcome page is opened immediately

I checked catalina.out when i see the page in browser, it says:

    Oct 17, 2014 2:31:47 PM org.apache.catalina.startup.HostConfig deployDirectory
    INFO: Deploying web application directory /usr/local/apache-tomcat-7.0.56-server-1/webapps/host-manager
    Oct 17, 2014 3:00:27 PM org.apache.catalina.util.SessionIdGenerator createSecureRandom
    INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took **[1,718,769] milliseconds.**

Memory:

               total       used       free     shared    buffers     cached
  Mem:       1017912     849512     168400        332      18780     688468

Replacing securerandom.source=file:/dev/urandom with securerandom.source=file:/dev/./urandom in $JAVA_PATH/jre/lib/security/java.security has solved my problem.

Even when file:/dev/urandom is specified, JRE will still use /dev/random for SHA1PRNG (see bug JDK-4705093):

> In SHA1PRNG, there is a SeedGenerator which does various things > depending on the configuration. > > 1. If java.security.egd or securerandom.source point to "file:/dev/random" or "file:/dev/urandom", we will use > NativeSeedGenerator, which calls super() which calls > SeedGenerator.URLSeedGenerator(/dev/random). (A nested class within > SeedGenerator.) The only things that changed in this bug was that > urandom will also trigger use of this code path. > > 2. If those properties point to another URL that exists, we'll initialize SeedGenerator.URLSeedGenerator(url). This is why > "file:///dev/urandom", "file:/./dev/random", etc. will work.

From Wikipedia on /dev/random:

> In this implementation, the generator keeps an estimate of the number > of bits of noise in the entropy pool. From this entropy pool random > numbers are created. When read, the /dev/random device will only > return random bytes within the estimated number of bits of noise in > the entropy pool. /dev/random should be suitable for uses that need > very high quality randomness such as one-time pad or key generation. > > When the entropy pool is empty, reads from /dev/random will block > until additional environmental noise is gathered. The intent is to > serve as a cryptographically secure pseudorandom number generator, > delivering output with entropy as large as possible. This is suggested > for use in generating cryptographic keys for high-value or long-term > protection.

Environmental noise?

> The random number generator gathers environmental noise from device > drivers and other sources into an entropy pool. The generator also > keeps an estimate of the number of bits of noise in the entropy pool. > From this entropy pool random numbers are created.

That means in practice, it’s possible to block tomcat for an unknown amount of time.

This also works:

> Actually, by setting the following in /etc/default/tomcat7, I was fine: > >JAVA_OPTS="-Djava.security.egd=file:/dev/./urandom -Djava.awt.headless=true -Xmx1024m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC"

Comment from :

https://www.digitalocean.com/community/tutorials/how-to-install-apache-tomcat-7-on-ubuntu-14-04-via-apt-get

While using /dev/urandom as the source for entropy is a workaround that reduces the startup time for Tomcat, it is not a good idea because it can have unintended side effects.

Other components running in the Tomcat server (e.g. web applications) might depend on a securely initialized SecureRandom instance and there might be security issues when the entropy for the random numbers is not sufficient.

Actually, this is one of the reasons why using /dev/urandom does not work, but /dev/./urandom does. The SHA1PRNG heavily relies on a good seed. If the seed is not good, the random numbers are predictable. Therefore, the developer ensured that for this purpose /dev/random is used as the source of entropy, even if the JVM is configured to use /dev/urandom. There are two bug reports about this (bug 1, bug 2).

So instead of changing the entropy source to /dev/urandom, one should rather make sure that /dev/random has enough entropy. If the system has a hardware RNG, installing rng-tools should do the trick. Otherwise, installing haveged provides a very good source of entropy that does not rely on a special hardware RNG to be present. In a virtual machine, rng-tools can use entropy from the host through a virtual hardware RNG. As an alternative to this, EGD could be used, but at the moment this software is not included in the Ubuntu repositories, so that it is bothersome to use it.