I am trying to launch a war (dss-server.war) file using Jetty on Ubuntu 13.10 Server using the Amazon EC2 service. The project in question uses maven, java, apache-camel, spring and SIGAR. However the process is killed for no apparent reason at all:
Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled in the future
2014-02-26 22:40:48.737:INFO:oejs.Server:jetty-8.1.14.v20131031
2014-02-26 22:40:48.798:INFO:oejdp.ScanningAppProvider:Deployment monitor /home/ubuntu/jetty-distribution-8.1.14.v20131031/webapps at interval 1
2014-02-26 22:40:48.814:INFO:oejd.DeploymentManager:Deployable added: /home/ubuntu/jetty-distribution-8.1.14.v20131031/webapps/dss-server.war
2014-02-26 22:40:49.096:INFO:oejw.WebInfConfiguration:Extract jar:file:/home/ubuntu/jetty-distribution-8.1.14.v20131031/webapps/dss-server.war!/ to /tmp/jetty-0.0.0.0-8080-dss-server.war-_dss-server-any-/webapp
2014-02-26 22:41:17.170:INFO:dss-server:No Spring WebApplicationInitializer types detected on classpath
2014-02-26 22:41:19.193:INFO:dss-server:Initializing Spring root WebApplicationContext
2014-02-26 22:41:32.409:INFO:dss-server:Initializing Spring FrameworkServlet 'dss'
Killed
I am launching the project using the following command line:
java -jar -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:PermSize=128M -XX:MaxPermSize=256M start.jar > output.txt
And the output file does not show anything incriminatory as well.
What am I missing?
Finally got it. The problem lies with OpenJDK. The previous configuration that I have mention will NOT work with openJDK (probably because Jetty does not like it). It has to be Java from oracle. I fixed the problem by installing Oracle's Java by following this article:
http://www.webupd8.org/2012/01/install-oracle-java-jdk-7-in-ubuntu-via.html
Related
This question already has answers here:
Unrecognized VM option 'UseParNewGC' , Error: Could not create the Java Virtual Machine
(5 answers)
Closed 14 days ago.
I recently upgraded Java and now Tomcat service won't start. This is on an Ubuntu 16.04 LTS server. Tomcat is version 8.5. I upgraded from Java 7 to Java 11, Azul Zulu 7 to Azul Zulu 11. When running systemctl status tomcat85 I see the following not particularly helpful output:
Although the service won't seem to work, I can start Tomcat manually with the following command:
/opt/tomcat85/bin/startup.sh
These are the contents of the service file:
[Unit]
Description=Apache Tomcat 8.5 Servlet Container
After=syslog.target network.target
[Service]
User=tomcat85
Group=tomcat85
Type=forking
Environment=JAVA_HOME=/usr/lib/jvm/zulu-11-amd64
Environment=CATALINA_PID=/opt/tomcat85/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat85
Environment=CATALINA_BASE=/opt/tomcat85
EnvironmentFile=/etc/default/tomcat85
WorkingDirectory=/opt/tomcat85
ExecStart=/opt/tomcat85/bin/startup.sh
ExecStop=/opt/tomcat85/bin/shutdown.sh
#Restart=on-failure
StandardOutput=syslog
StandardError=syslog
LimitNOFILE=65536
SyslogIdentifier=tomcat85
[Install]
WantedBy=multi-user.target
Running journalctl -xe provides no meritorious information.
catalina.out reveals the following error:
I'm not sure where to go next with troubleshooting this issue. There are several seemingly related discussions on Stack but none have provided a solution as of yet. Any help is appreciated and I'm happy to add more information as requested.
I have found the answer thanks to some good feedback here in this post. The problem was several deprecated entries in the EnvironmentFile:
/etc/default/tomcat85
JAVA_OPTS="-server -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseTLAB -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:PermSize=1024M -XX:MaxPermSize=1024m -Xms16384m -Xmx20480m"
One of the errant entries was:
-XX:+UseParNewGC
The updated entry is:
-XX:+UseG1GC
Additionally the following entries needed to be removed:
UseConcMarkSweepGC
PermSize
MaxPermSize
I have Ubuntu server on my computer and i have the tomcat9 there.
Last night everything was going well, put .war into webapp folder and it would run like it should on localhost:8080/app
Then i went to sleep and was prepared to continue from where i left off, but behold, yet again there is a problem with tomcat!
i restarted the server, went to /opt/tomcat9/bin and ran startup.sh
Using CATALINA_BASE: /opt/tomcat9
Using CATALINA_HOME: /opt/tomcat9
Using CATALINA_TMPDIR: /opt/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/java-8-oracle/jre
Using CLASSPATH: /opt/tomcat9/bin/bootstrap.jar:/opt/tomcat9/bin/tomcat-juli.jar
Tomcat started.
but at localhost:8080 is now unable to connect, as is the /app folder too.
In logs there is nothing....
It seems it dosent even write into logs anymore, last log post is
from last night, despite running the server 5min ago.
Catalinalog (timestamp from last night)
07-Mar-2017 04:20:49.775 WARNING [http-nio-8080-exec-9] org.springframework.web.servlet.PageNotFound.noHandlerFound No mapping found for HTTP request with URI [/spring3-mvc-maven-xml-hello-world/hello2] in DispatcherServlet with name 'spring-web'
Catalina.out (also from last night)
07-Mar-2017 04:20:49.775 WARNING [http-nio-8080-exec-9] org.springframework.web.servlet.PageNotFound.noHandlerFound No mapping found for HTTP request with URI [/spring3-mvc-maven-xml-hello-world/hello2] in DispatcherServlet with name 'spring-web'
./catalina.sh: 1: eval: /usr/lib/jvm/java-8-oracle/jre/bin/java: not found
./catalina.sh: 1: eval: /usr/lib/jvm/java-8-oracle/jre/bin/java: not found
./catalina.sh: 1: eval: /usr/lib/jvm/java-8-oracle/jre/bin/java: not found
./catalina.sh: 1: eval: /usr/lib/jvm/java-8-oracle/jre/bin/java: not found
./catalina.sh: 1: eval: /usr/lib/jvm/java-8-oracle/jre/bin/java: not found
Am i really just bad with the service or what, it feels like majority, somewhere around 70% of my time is wasted on debuggin Tomcat alone,
I would totally love to actually work on my project instead of tomcat...
Seems your Java Runtime Environment is missing
That end of the catalina.out is rather revealing: it cannot seem to find the java executable!
Try in a terminal to write
/usr/lib/jvm/java-8-oracle/jre/bin/java -version
Unless you get something along these lines...
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)
...then it is not your Tomcat that is broken but your Java Runtime Environment.
For Linux,
you can default set by using the following command.
sudo update-alternatives --config java
For more, you can go through this link: https://stackoverflow.com/a/37479837/2293534
Java Full Installation in Linux: https://www.digitalocean.com/community/tutorials/how-to-install-java-on-ubuntu-with-apt-get
For windows,
you can follow this link: https://confluence.atlassian.com/doc/setting-the-java_home-variable-in-windows-8895.html
UPDATE:
Run the following command
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH
export JRE_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre
UPDATE#2:
This is a suggestion. You can reinstall java8 and tomcat9 after removing current installation.
Full installation procedure is given here: https://tecadmin.net/install-tomcat-9-on-ubuntu/
Another installation procedure is also given here: http://www.linuxtechi.com/install-apache-tomcat9-centos7-rhel7-ubuntu16-04/
My apps are web app projects (java liberty pack).
I want to run executables with java process builder in servlets but I am getting errors. That executables depends to GLIBC.
How can I solve them?
First project:
libstdc++.so.6: version `GLIBCXX_3.4.20' not found
Second Project:
/lib/libc.so.6: version `GLIBC_2.14' not found
Cloud Foundry supports "stacks" which define the operating system runtime your application will be deployed onto.
[10:04:11 ~]$ cf stacks
Getting stacks in org james.thomas#uk.ibm.com / space dev as james.thomas#uk.ibm.com...
OK
name description
lucid64 Ubuntu 10.04
seDEA private
cflinuxfs2 Ubuntu 14.04.2 trusty
Currently, IBM Bluemix is deploying applications onto the older Ubuntu 10.04 stack by default. This environment contains GLIBC 2.11.
You can specify which stack to deploy your application onto using the "-s" command line flag or setting this in the manifest.
Choosing cflinuxfs2 will use a more recent version of Ubuntu with an updated version of the glibc libraries.
This should hopefully work.
Currently we are having various problems with the deployment of our Grails application on Tomcat 6, mainly it's about memory usage issues and redeployment via Jenkins.
The Application eats more and more memory, and we tried to resolve this with CMSPermGenSweepingEnabled (we are using UseConcMarkSweepGC), so now the temporary classes used by Groovy should get cleaned up.
What still is a problem is that on each Redeploy (with jenkins) the app needs around 150 mb of additional Permgen space ... any idea how to avoid this?
We are using Grail 1.3.7, and our current configuration flags are
-Djava.util.logging.config.file=/var/lib/tomcat6/conf/logging.properties
-Djava.awt.headless=true
-Xms2048M
-Xmx2048M
-XX:MaxPermSize=1024m
-XX:PermSize=1024m
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled
-XX:+UseConcMarkSweepGC
-Djava.net.preferIPv4Stack=true
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
-Dcatalina.base=/var/lib/tomcat6
-Dcatalina.home=/usr/share/tomcat6
-Djava.io.tmpdir=/tmp/tomcat6-tmp
It's very popular tomcat issue, they even have some recommendations: http://wiki.apache.org/tomcat/OutOfMemory, but at most cases it's works only for small or fully controlled project (mean 'project without any external library'). All solid projects I ever seen fails under tomcat with this error :(
My recomendation - restart Tomcat instance after deploy.
We've experienced similar issues with our Grails applications on Tomcat. Our solution is the same as what Igor suggests, restart Tomcat after a deploy.
We have two production servers setup in a cluster so they share sessions. We take one server down, undeploy the application, restart tomcat, deploy the new version of the application, and bring that server back up. Then repeat the process on the other server. So far this is working for us.
I'm new to Linux but having spent a whole day I Installed Java and Tomcat. My goal is to host an App with this Linux box. I know it all works fine from my windows based machine, but it is my laptop so I'm planning to use the Linux Box as my dedicated server.
Following many many forums I've now got Tomcat 7 installed. However i cannot get it to start.
Changing to the tomcat directory and "./startup.sh" i get the following output:
Using CATALINA_BASE: /usr/local/tomcat
Using CATALINA_HOME: /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JRE_HOME: usr/lib/jvm/java-6-sun/
Using CLASSPATH: /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
That's the end of the output.
However localhost:8080 is not up, and in the tomcat log file is the error "eval: 1: usr/lib/jvm/java-6-sun//bin/java: not found"
Hopefully there is some expert here who can help me with this problem. Please note that I'm a novice when it comes to Linux.
PS: My Linux version is Ubuntu 10.04 LTS - the Lucid Lynx
JRE_HOME is missing a / at the start of it.
Your CATALINA_HOME and CLASSPATH also looks wrong, with a local.tomcat instead of a local/tomcat and c\tomcat-juli instead of tomcat-juli
Try typing this on the command line:
$ export CATALINA_HOME=/usr/local/tomcat
$ export JRE_HOME=/usr/lib/jvm/java-6-sun
$ /usr/local/tomcat/bin/catalina.sh run
This will run Tomcat in the terminal you have open, so you can watch it do stuff. Press CTRL+C to quit it.
First download the Linux tomcat version.
Unzip it.
Go to the tomcat bin folder.
Run the startup.sh for start the tomcat server
Shutdown.sh for using to stop the tomcat
see the link,
http://brigitzblog.blogspot.com/2011/11/linux-how-can-i-startstop-tomcat-server.html
I'm just posting in case this will help someone else. I had my JAVA_HOME set to
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/java
I should have been
/usr/lib/jvm/java-7-openjdk-i386/jre
without the /bin/java part at the end. This is because will look for bin/java in that path already and you don't need to specify it.
When I encountered something similar, the problems was with my Tomcat7 installation. I downgraded to Tomcat6 and it started working perfectly.