Develop Reference

Tomcat 9 no longer starting using systemctl but will start manually

Been digging on this for a while. I reviewed multiple articles on this issue. This one was the closest:
Tomcat 8 on CentOS 7 does not start as service (but it starts manually ....)
The difference being that I am running Tomcat 9.0.33. Here are the particulars:
java version "1.8.0_121"\
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)\
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)\
Tomcat 9.0.33
NAME="CentOS Linux"\
VERSION="7 (Core)"\
ID="centos"\
ID_LIKE="rhel fedora"\
VERSION_ID="7"\
PRETTY_NAME="CentOS Linux 7 (Core)"\
ANSI_COLOR="0;31"\
CPE_NAME="cpe:/o:centos:centos:7"\
HOME_URL="https://www.centos.org/"\
BUG_REPORT_URL="https://bugs.centos.org/"\
CENTOS_MANTISBT_PROJECT="CentOS-7"\
CENTOS_MANTISBT_PROJECT_VERSION="7"\
REDHAT_SUPPORT_PRODUCT="centos"\
REDHAT_SUPPORT_PRODUCT_VERSION="7"\
As a side note, everything was starting normally with no issues until recently. As far as I know there haven't been any major changes to the environment. But, when I ran the "systemctl restart" command recently, the startup began to fail. There are 5 instances of Tomcat 9.0.33 running at different ports and paths and those have not changed. I have not restarted two of the instance (afraid they won't start) the other three flat out won't start. Details below:
Systemd unit file for tomcat\
[Unit]\
Description=Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT\
After=syslog.target network.target
[Service]\
Type=forking
Environment=JAVA_HOME=/opt/jdk1.8.0_121/jre\
Environment=CATALINA_PID=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/temp/tomcat.pid\
Environment=CATALINA_HOME=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33\
Environment=CATALINA_BASE=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33\
Environment='CATALINA_OPTS=-Xms1024m -Xmx2048m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=20 -XX:ParallelGCThreads=8 -server -Xdebug -Xrunjdwp:transport=dt_socket,address=5000,server=y,suspend=n'\
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom -Duser.timezone=GMT -Dfile.encoding=UTF-8'
ExecStart=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh\
ExecStop=/bin/kill -15 $MAINPID
User=tomcat\
Group=tomcat\
UMask=0007
[Install]\
WantedBy=multi-user.target\
Results when running systemctl start liferayuat
● liferayuat.service - Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT\
Loaded: loaded (/etc/systemd/system/liferayuat.service; enabled; vendor preset: disabled)\
Active: failed (Result: exit-code) since Sat 2020-12-05 08:44:08 CST; 3s ago\
Process: 10891 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=1/FAILURE)\
Process: 10851 ExecStart=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh \(code=exited, status=0/SUCCESS)\
Main PID: 10861 (code=exited, status=0/SUCCESS)
Dec 05 08:44:08 systemd[1]: Starting Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT...\
Dec 05 08:44:08 startup.sh[10851]: Existing PID file found during start.\
Dec 05 08:44:08 startup.sh[10851]: Removing/clearing stale PID file.\
Dec 05 08:44:08 startup.sh[10851]: Tomcat started.\
Dec 05 08:44:08 systemd[1]: Started Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT.\
Dec 05 08:44:08 systemd[1]: liferayuat.service: control process exited, code=exited status=1\
Dec 05 08:44:08 systemd[1]: Unit liferayuat.service entered failed state.\
Dec 05 08:44:08 systemd[1]: liferayuat.service failed.
Then the ONLY thing in catalina.out:
Listening for transport dt_socket at address: 5000\
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina\
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)\
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)\
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)\
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:261)\
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:443)\
So, when I start the instance with systemctl start it will fail. But if I run this command (as root...) then it will start:
/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh
If I run that full commmand AS tomcat it doesn't start with the same error. So, it appears that the issue is permissions. The tomcat user and group are owners of all files and folders. But, somehow, the tomcat user either doesn't have permissions or the path gets jacked up so that the class files can't be found. I followed the suggestions in the article I referenced above but the changes had no impact.
I tripped across one article on SELINX that seemed to point to an issue there. This are the SELINUX settings:
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31\
The workaround to keep the instances running is just to manually start them but what is causing systemctl start NOT to work? I suspect permissions but I sure as heck can't see why since everything is owned by tomcat:tomcat

So, this is self-inflicted as most "mysteries" are. I still cannot account for some of the differences I see when looking into SELinux contexts between the instances but the REAL cause was subtle (to me). Permissions on the {tomcat root}/lib and {tomcat root}/lib/ext had no execute permissions. That may have been due to a jar that was added recently and then needed to be updated by owner and permissions. In any case, the original issue resulted in many trial and error attempts to fix it which complicated matters further.
I discovered the solution by doing a folder by folder, file by file comparison between working and non-working instances. Apparently the new jar and the owner/permission changes were applied to all but the production version.
Thanks for the suggestions.

java NIO memory map a docker mounted file fail

I recently run into docker and deploy my java application into a tomcat docker container. But I met a very specific error about NIO memory mapping a file:
File mark = new File("/location/to/docker/mounted/file");
m_markFile = new RandomAccessFile(mark, "rw");
MappedByteBuffer m_byteBuffer = m_markFile.getChannel().map(MapMode.READ_WRITE, 0, 20);
And the last function call failed as:
Caused by: java.io.IOException: Invalid argument
at sun.nio.ch.FileChannelImpl.map0(Native Method)
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:906)
at com.dianping.cat.message.internal.MessageIdFactory.initialize(MessageIdFactory.java:127)
at com.dianping.cat.message.internal.DefaultMessageManager.initialize(DefaultMessageManager.java:197)
... 34 more
I don't know what happened. I tested it in my local Mac environment, it's ok. And within the tomcat docker container, I change the file location to a normal file path, it's ok too. Seems which happens only on docker mounted file.
Other information:
root#4520355ed3ac:/usr/local/tomcat# uname -a
Linux 4520355ed3ac 4.4.27-boot2docker #1 SMP Tue Oct 25 19:51:49 UTC 2016 x86_64 GNU/Linux
Mounted a folder in Mac Users to /data
root#4520355ed3ac:/usr/local/tomcat# df
Filesystem 1K-blocks Used Available Use% Mounted on
none 18745336 6462240 11292372 37% /
tmpfs 509832 0 509832 0% /dev
tmpfs 509832 0 509832 0% /sys/fs/cgroup
Users 243924992 150744296 93180696 62% /data
/dev/sda1 18745336 6462240 11292372 37% /etc/hosts
shm 65536 0 65536 0% /dev/shm
docker version
huanghaideMacBook-Pro:cat huanghai$ docker --version
Docker version 1.12.3, build 6b644ec
huanghaideMacBook-Pro:cat huanghai$ docker-machine --version
docker-machine version 0.8.2, build e18a919

Proton CEP: 100% CPU usage after a few hours

I have a Proton CEP instance deployed on my own server with 2 CPUs and 4GB RAM.
After leaving it working overnight, CPU usage increases heavily, up to 100% of each core. The command being executed is:
java -Djava.security.egd=file:/dev/./urandom -Djava.awt.headless=true -Xmx512m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start
Looking at the logs, I also see:
Feb 17, 2016 10:00:00 AM com.ibm.hrl.proton.server.executorServices.SimpleThreadFactory$ProtonExceptionHandler uncaughtException
SEVERE: Uncaught exception in thread: Thread[31516,5,main],exception: Java heap space
Feb 17, 2016 10:02:31 AM com.ibm.hrl.proton.server.executorServices.SimpleThreadFactory$ProtonExceptionHandler uncaughtException
SEVERE: Uncaught exception in thread: Thread[31643,5,main],exception: Java heap space
Althought from htop it seems that up to 2 GB of RAM are still free.
Is this normal?
The same server is also running Orion, but that one is not experiencing issues.

The problem was that due to a bug in our code, we were sending ever larger requests with data to Orion which forwarded them to Proton. Eventually the requests grew from 100B to over 50MB, causing Proton to stall as it was unable to process all the data in time.

Tomcat7 CentOS Service Start fail

I am having issues with auto-loading tomcat7. This is the init.d script:
#!/bin/bash
# chkconfig: 2345 80 20
# Description: Tomcat Server basic start/shutdown script
# /etc/init.d/tomcat7 -- startup script for the Tomcat 7 servlet engine
TOMCAT_HOME=/usr/local/tomcat7/bin
START_TOMCAT=/usr/local/tomcat7/bin/startup.sh
STOP_TOMCAT=/usr/local/tomcat7/bin/shutdown.sh
start() {
echo -n "Starting tomcat7: "
cd $TOMCAT_HOME
${START_TOMCAT}
echo "done."
}
stop() {
echo -n "Shutting down tomcat7: "
cd $TOMCAT_HOME
${STOP_TOMCAT}
echo "done."
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
sleep 10
start
;;
*)
echo "Usage: $0 {start|stop|restart}"
esac
exit 0
When starting like so:
>service tomcat7 start
Starting tomcat7:
Using CATALINA_BASE: /usr/local/tomcat7
Using CATALINA_HOME: /usr/local/tomcat7
Using CATALINA_TMPDIR: /usr/local/tomcat7/temp
Using JRE_HOME: /usr
Using CLASSPATH: /usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
Tomcat started.
done.
Tomcat does not seem to not be able to load a properties file from apache commons. Does anyone know why this is ?
The file is:
user-config.properties
found in:
/usr/local/tomcat7/conf
Everything works fine when running directly like so:
/usr/local/tomcat7/bin/startup.sh
Using CATALINA_BASE: /usr/local/tomcat7
Using CATALINA_HOME: /usr/local/tomcat7
Using CATALINA_TMPDIR: /usr/local/tomcat7/temp
Using JRE_HOME: /usr
Using CLASSPATH: /usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
Tomcat started.
Run Through:
%> service tomcat7 start
Starting tomcat7: Using CATALINA_BASE: /usr/local/tomcat7
Using CATALINA_HOME: /usr/local/tomcat7
Using CATALINA_TMPDIR: /usr/local/tomcat7/temp
Using JRE_HOME: /usr
Using CLASSPATH: /usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
Tomcat started.
done.
%> ps -aux |grep tomcat
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
root 26657 60.4 8.5 7181652 1385552 pts/0 Sl 16:11 0:15 /usr/bin/java -Djava.util.logging.config.file=/usr/local/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/tomcat7/endorsed -classpath /usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat7 -Dcatalina.home=/usr/local/tomcat7 -Djava.io.tmpdir=/usr/local/tomcat7/temp org.apache.catalina.startup.Bootstrap start
root 26706 0.0 0.0 103252 844 pts/0 S+ 16:11 0:00 grep tomcat
Now I load the webpage with causes the error
HTTP Status 500 - java.lang.ExceptionInInitializerError
type Exception report
message java.lang.ExceptionInInitializerError
description The server encountered an internal error that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: java.lang.ExceptionInInitializerErrorcom.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:420)com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)javax.servlet.http.HttpServlet.service(HttpServlet.java:727)org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)com.ftw.tme.filter.SessionFilter.doFilter(SessionFilter.java:130)
root cause
java.lang.ExceptionInInitializerErrorcom.ftw.tme.authentication.service.impl.AuthenticationServiceImpl.<init>(AuthenticationServiceImpl.java:27)com.ftw.tme.rest.AuthenticationRestService.<init>(AuthenticationRestService.java:38)sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)java.lang.reflect.Constructor.newInstance(Constructor.java:526)com.sun.jersey.server.spi.component.ResourceComponentConstructor._construct(ResourceComponentConstructor.java:245)com.sun.jersey.server.spi.component.ResourceComponentConstructor.construct(ResourceComponentConstructor.java:233)com.sun.jersey.server.impl.resource.PerRequestFactory$PerRequest._getInstance(PerRequestFactory.java:182)com.sun.jersey.server.impl.resource.PerRequestFactory$AbstractPerRequest.getInstance(PerRequestFactory.java:144)com.sun.jersey.server.impl.application.WebApplicationContext.getResource(WebApplicationContext.java:239)com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)javax.servlet.http.HttpServlet.service(HttpServlet.java:727)org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)com.ftw.tme.filter.SessionFilter.doFilter(SessionFilter.java:130)
root cause
java.lang.NullPointerExceptionjava.lang.String.replace(String.java:2180)com.ftw.tme.commons.db.util.tmeConfigUtils.<clinit>(tmeConfigUtils.java:71)com.ftw.tme.authentication.service.impl.AuthenticationServiceImpl.<init>(AuthenticationServiceImpl.java:27)com.ftw.tme.rest.AuthenticationRestService.<init>(AuthenticationRestService.java:38)sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)java.lang.reflect.Constructor.newInstance(Constructor.java:526)com.sun.jersey.server.spi.component.ResourceComponentConstructor._construct(ResourceComponentConstructor.java:245)com.sun.jersey.server.spi.component.ResourceComponentConstructor.construct(ResourceComponentConstructor.java:233)com.sun.jersey.server.impl.resource.PerRequestFactory$PerRequest._getInstance(PerRequestFactory.java:182)com.sun.jersey.server.impl.resource.PerRequestFactory$AbstractPerRequest.getInstance(PerRequestFactory.java:144)com.sun.jersey.server.impl.application.WebApplicationContext.getResource(WebApplicationContext.java:239)com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540)com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715)javax.servlet.http.HttpServlet.service(HttpServlet.java:727)org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)com.ftw.tme.filter.SessionFilter.doFilter(SessionFilter.java:130)
%> ps -aux |grep tomcat
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
root 26657 19.2 8.6 7718532 1397424 pts/0 Sl 16:11 0:15 /usr/bin/java -Djava.util.logging.config.file=/usr/local/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/tomcat7/endorsed -classpath /usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat7 -Dcatalina.home=/usr/local/tomcat7 -Djava.io.tmpdir=/usr/local/tomcat7/temp org.apache.catalina.startup.Bootstrap start
root 26727 0.0 0.0 103252 844 pts/0 S+ 16:12 0:00 grep tomcat
[user#localhost bin]#

Looks like an NPE in your own code:
root cause
java.lang.NullPointerException
java.lang.String.replace(String.java:2180)
com.ftw.tme.commons.db.util.tmeConfigUtils.<clinit>(tmeConfigUtils.java:71)
com.ftw.tme.authentication.service.impl.AuthenticationServiceImpl.<init>(AuthenticationServiceImpl.java:27)
com.ftw.tme.rest.AuthenticationRestService.<init>(AuthenticationRestService.java:38)

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.
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.
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.