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.
I am following this tutorial . From this tutorial I have executed the following command :
cd /etc/init.d
vi tomcat
#!/bin/bash
# description: Tomcat Start Stop Restart
# processname: tomcat
# chkconfig: 234 20 80
JAVA_HOME=/usr/java/jdk1.7.0_05
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
CATALINA_HOME=/usr/share/apache-tomcat-7.0.29
case $1 in
start)
sh $CATALINA_HOME/bin/startup.sh
;;
stop)
sh $CATALINA_HOME/bin/shutdown.sh
;;
restart)
sh $CATALINA_HOME/bin/shutdown.sh
sh $CATALINA_HOME/bin/startup.sh
;;
esac
exit 0
chmod 755 tomcat
chkconfig --add tomcat
chkconfig --level 234 tomcat on
chkconfig --list tomcat
service tomcat start
After this command , tomcat is started at port 8082 . But when I restart pc , the tomcat is not started with boot of PC .
How can I do this ?
Since you use Red Hat you can use systemd for services.
Create a file /etc/systemd/system/tomcat.service:
[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target
[Service]
Type=forking
Environment=JAVA_HOME=/usr/java/jdk1.7.0_05
Environment=CATALINA_PID=/usr/share/apache-tomcat-7.0.29/temp/tomcat.pid
Environment=CATALINA_HOME=/usr/share/apache-tomcat-7.0.29
Environment=CATALINA_BASE=/usr/share/apache-tomcat-7.0.29
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Duser.timezone=UTC -Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'
ExecStart=/usr/share/apache-tomcat-7.0.29/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID
User=tomcat
Group=tomcat
[Install]
WantedBy=multi-user.target
I specified the script to start after syslog and network are enabled.
As we can see systemd handles the tomcat as a daemon and kills the PID.
With User and Group we specify the user and the group that the process should be run as.
Systemd will handle the upstart process and kill it using the PID.
To enable it to run then issue:
systemctl enable tomcat
systemctl start tomcat
Try to use this command instead:
sudo systemctl enable tomcat
I have a Vagrant CentOS VM running with ps.memory = 2048 RAM allocated.
When I try to start the puppetserver service:
$ puppet --version
4.4.0
$ sudo puppet resource service puppetserver ensure=running
Error: Could not start Service[puppetserver]: Execution of '/bin/systemctl start puppetserver' returned 1: Job for puppetserver.service failed. See 'systemctl status puppetserver.service' and 'journalctl -xn' for details.
Error: /Service[puppetserver]/ensure: change from stopped to running failed: Could not start Service[puppetserver]: Execution of '/bin/systemctl start puppetserver' returned 1: Job for puppetserver.service failed. See 'systemctl status puppetserver.service' and 'journalctl -xn' for details.
service { 'puppetserver':
ensure => 'stopped',
}
$ journalctl -xn
No journal files were found.
$ systemctl status puppetserver.service
puppetserver.service - puppetserver Service
Loaded: loaded (/usr/lib/systemd/system/puppetserver.service; disabled)
Process: 4708 ExecStartPre=/usr/bin/install --directory --owner=puppet --group=puppet --mode=775 /var/run/puppetlabs/puppetserver (code=exited, status=0/SUCCESS)
Main PID: 4709 (java); : 4710 (bash)
CGroup: /system.slice/puppetserver.service
├─4709 /usr/bin/java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError=kill -9 %p -Djava.security.egd=/...
└─control
├─4710 /bin/bash /opt/puppetlabs/server/apps/puppetserver/ezbake-functions.sh wait_for_app
└─4755 sleep 1
My JAVA_ARGS from /etc/sysconfig/puppetserver:
JAVA_ARGS="-Xms1g -Xmx1g -XX:MaxPermSize=1g"
As requested, the puppetserver.service file:
$ cat /usr/lib/systemd/system/puppetserver.service
[Unit]
Description=puppetserver Service
After=syslog.target network.target
[Service]
Type=simple
EnvironmentFile=/etc/sysconfig/puppetserver
User=puppet
TimeoutStartSec=120
TimeoutStopSec=60
Restart=on-failure
StartLimitBurst=5
PermissionsStartOnly=true
ExecStartPre=/usr/bin/install --directory --owner=puppet --group=puppet --mode=775 /var/run/puppetlabs/puppetserver
ExecStart=/usr/bin/java $JAVA_ARGS \
'-XX:OnOutOfMemoryError=kill -9 %%p' \
-Djava.security.egd=/dev/urandom \
-cp "${INSTALL_DIR}/puppet-server-release.jar" clojure.main \
-m puppetlabs.trapperkeeper.main \
--config "${CONFIG}" \
-b "${BOOTSTRAP_CONFIG}" $#
KillMode=process
ExecStartPost=/bin/bash "${INSTALL_DIR}/ezbake-functions.sh" wait_for_app
SuccessExitStatus=143
StandardOutput=syslog
[Install]
WantedBy=multi-user.target
An attempt at running the ExecStartPost command by hand:
$ /usr/bin/java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg
RuntimeError: Got 2 failure(s) while initializing: File[/var/log/puppetlabs/puppetserver]: change from 0700 to 0750 failed: failed to set mode 0700 on /var/log/puppetlabs/puppetserver: Operation not permitted - No message available; File[/var/run/puppetlabs/puppetserver]: change from 0775 to 0755 failed: failed to set mode 0775 on /var/run/puppetlabs/puppetserver: Operation not permitted - No message available
So I tried again, but this time I changed some directory permissions, but still similar error (which doesn't make sense given I just changed the mode?):
$ sudo chown -R vagrant:vagrant /var/run/puppetlabs/
$ sudo chown -R vagrant:vagrant /var/log/puppetlabs/
$ sudo chmod -R 0755 /var/run/puppetlabs/
$ /usr/bin/java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=1g; support was removed in 8.0
RuntimeError: Got 1 failure(s) while initializing: File[/var/run/puppetlabs/puppetserver]: change from 0775 to 0755 failed: failed to set mode 0775 on /var/run/puppetlabs/puppetserver: Operation not permitted - No message available
use at /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/settings.rb:1007
What could be the issue?
Are you certain that it’s an OnOutOfMemory error? I ask because I found that the latest PuppetServer includes a newer version of logback, as shown by this message in /var/log/messages:
Mar 18 01:56:21 puppetserver java: Exception in thread "main" java.lang.AbstractMethodError: ch.qos.logback.core.net.SyslogAppenderBase.createOutputStream()Lch/qos/logback/core/net/SyslogOutputStream;
Mar 18 01:56:21 puppetserver java: at ch.qos.logback.core.net.SyslogAppenderBase.start(SyslogAppenderBase.java:62)
Mar 18 01:56:21 puppetserver java: at ch.qos.logback.classic.net.SyslogAppender.start(SyslogAppender.java:48)
If you see, this replace “classic.net.Syslog” in logback.xml with "core.net.Syslog"
sed -i_old -e 's/classic.net.Syslog/core.net.Syslog/' /etc/puppetlabs/puppetserver/logback.xml
If that's not the problem, please post your logfiles.
You have provided log as
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=1g;
support was removed in 8.0
So, it is clear that you are using jdk 8 which removed permgen space.
The Permanent Generation (PermGen) space has completely been removed and is kind of replaced by a new space called Metaspace. The consequences of the PermGen removal is that obviously the PermSize and MaxPermSize JVM arguments are ignored and you will never get a java.lang.OutOfMemoryError: PermGen error.
So please remove the -XX:MaxPermSize=1g portion from JAVA_ARGS of location /etc/sysconfig/puppetserver
JAVA_ARGS="-Xms1g -Xmx1g"
So
And then,
your command will be look like below:
$ /usr/bin/java -Xms1g -Xmx1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg
or
$ /usr/bin/java -Xms1g -Xmx1g -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg
Please try this 2 commands. I hope both will run successfully. For caution purpose, I have added both.
N.B: There is no need to change the file permission. keep them as before you using.
Otherwise, if you don't want to change anything, you can downgrade java 8 to java 7
Related Link:
PermGen elimination in JDK 8
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize
JAVA 8 XX:PERMSIZE AND XX:MAXPERMSIZE DISAPPEARING
JDK 8 Milestones
JEP 122: Remove the Permanent Generation
#lollercoster, you're starting your service with:
sudo puppet resource service puppetserver ensure=running
But your next command is not telling which user it is
/usr/bin/java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg
Please run whoami directly before your run the above command:
whoami
/usr/bin/java -Xms1g -Xmx1g -XX:MaxPermSize=1g -XX:OnOutOfMemoryError='kill -9 %%p' -Djava.security.egd=/dev/urandom -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d -b /etc/puppetlabs/puppetserver/bootstrap.cfg
Why this commands?
I am pretty confident that your issue is a permission/usercontext issue and following commands make it more worse:
$ sudo chown -R vagrant:vagrant /var/run/puppetlabs/
$ sudo chown -R vagrant:vagrant /var/log/puppetlabs/
$ sudo chmod -R 0755 /var/run/puppetlabs/
with the above cases you have to do a sudo on the right user context to have the files writable, but it depends if the other data is writable. So you can give it a try, but I would use the puppet user created for the service
User=puppet
So your puppet service runs as user puppet, but your logfiles are under vagrant user control, and not writable for puppet user.
So I would also try to switch back to:
$ sudo chown -R puppet /var/run/puppetlabs/
$ sudo chown -R puppet /var/log/puppetlabs/
$ sudo chmod -R 0755 /var/run/puppetlabs/
Java
Also I suggest you NOT to mess around with the JVM heap parameters, except you know what you do. Since you do not need to enforce a lower and a max bound on Java VM heap since JDK5. I would only limit to the upper bound
-Xmx1g
The heap and the real allocated mem will be managed well by the javaVM. As JVM needs more it will step by step increase the heap and keep the needed size (no downsizing to a lower value will occur). So you will have a better used RAM on your machine.
Also please switch to the Oracle JVM. I am facing often issues with security and Compatibility with OpenJDK. So my first test is to run it on the latest needed JDK of Oracle. In your case Oracle JDK8.
But please try first the permission things I mentioned before.
Good luck, and please keep me updated.
I have seen this behaviour before. Do not try to run the commands manually as root, because you will mess up the permissions. Instead read the logs carefully with journalctl -xe and try to understand why the service is failing. In my case I could not start the puppetserver service because there was already a private key, but not yet a public certificate.
ls /etc/puppetlabs/puppet/ssl/certs/`hostname -f`.pem
ls /etc/puppetlabs/puppet/ssl/private_keys/`hostname -f`.pem
If one of them is present without the other one, the service will fail to start up. You will see something like this in the log file:
Exception in thread "main" java.lang.IllegalStateException: Cannot initialize master with partial state; need all files or none.
If you are trying to install puppetserver for the first time, so there is no way to break an existing deployment, then you can probably just remove the exisiting private key and puppetserver will automatically generate a new pair.
rm /etc/puppetlabs/puppet/ssl/certs/`hostname -f`.pem
rm /etc/puppetlabs/puppet/ssl/private_keys/`hostname -f`.pem
And finally try again to start the puppetserver service.
service puppetserver start
/usr/bin/java -Xms1g -Xmx1g -XX:MaxPermSize=1g
Xms and Xms are less than MaxPermSize. this worked for me.
I am using RHEL 7 os with this i am using apache tomcat6. while try to start it using this command i am getting this message as:
Starting tomcat6: /etc/init.d/tomcat6: line 70: checkpid: command not found
and at line number 70 the code is as:
if checkpid $kpid 2>&1; then
echo "process allready running"
return -1
else
echo "lock file found but no process running for pid $kpid, continuing"
fi
after this execute the command i got process id for tomcat by this command:
[root#localhost ~]# ps -ef | grep tomcat
root 14074 13882 0 01:50 pts/1 00:00:00 grep --color=auto tomcat
but my war file is not deployed and also localhost:8080 is not working.
I have installed JAVA 1.7_80 in my centOS machine, but when I check the Java version it shows 1.7_09.
I ran the ./java -version in the installation directory which correctly shows 1.7_80, but the global java -version is 1.7_09.
Please refer the link for image -
https://scontent.xx.fbcdn.net/hphotos-xft1/v/t1.0-9/11667333_914348581933741_3461411661734554342_n.jpg?oh=e8d3037e2f6492757b0f786bd0ae8f77&oe=56318F12
Does someone know what could be the cause or how to fix this?
There's default OpenJDK in CentOS,
OPTION A
You have to install JDK with alternatives.
# cd /opt/jdk1.8.0_101/
# alternatives --install /usr/bin/java java /opt/jdk1.8.0_101/bin/java 2
# alternatives --config java
THE OUTPUT ==>
There are 2 programs which provide 'java'.
Selection Command
-----------------------------------------------
1 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/bin/java
+ 2 /opt/jdk1.8.0_101/bin/java
Enter to keep the current selection[+], or type selection number:
Select the version you want from this list.
OR : OPTION B
#ls -l /usr/bin/java
OUTPUT : . 1 root root 22 සැප් 9 02:09 /usr/bin/java -> /etc/alternatives/java
then # ls -l /etc/alternatives/java
OUTPUT : . 1 root root 26 සැප් 9 02:09 /etc/alternatives/java -> /opt/jdk1.8.0_101/bin/java
#unlink /etc/alternatives/java
#ln -s <new location> /etc/alternatives/java
(ln -s <original file> <link to file> )
But I prefer the option A.
The problem is, we changed that from MaxPermSize-128m to MaxPermSize=128m
but the system keeps giving us that error:
We even restarted Jenkins.
Is it caching something, or there is more than one place where this setting should be changed?
[workspace] $ /usr/lib/jvm/java-6-openjdk-amd64/bin/java -Xmx512m -XX:MaxPermSize-128m -cp /mnt/www/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.3.jar:/mnt/www/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.1.0/boot/plexus-classworlds-2.4.2.jar org.jvnet.hudson.maven3.agent.Maven3Main /mnt/www/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.1.0 /var/cache/jenkins/war/WEB-INF/lib/remoting-2.28.jar /mnt/www/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.3.jar 55896
Unrecognized VM option 'MaxPermSize-128m'
Could not create the Java virtual machine.
ERROR: Failed to launch Maven. Exit code = 1
the output of 'ps -ef | grep java' is:
root 3509 1 0 Jul12 ? 00:07:17 /usr/local/share/elasticsearch/bin/service/exec/elasticsearch-linux-x86-64 /usr/local/share/elasticsearch/bin/service/elasticsearch.conf wrapper.syslog.ident=elasticsearch wrapper.pidfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.pid wrapper.name=elasticsearch wrapper.displayname=ElasticSearch wrapper.daemonize=TRUE wrapper.statusfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.status wrapper.java.statusfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.java.status wrapper.script.version=3.5.14
root 3511 3509 0 Jul12 ? 00:45:11 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java -Delasticsearch-service -Des.path.home=/usr/local/share/elasticsearch -Xss256k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -Djava.awt.headless=true -Xms1024m -Xmx1024m -Djava.library.path=/usr/local/share/elasticsearch/bin/service/lib -classpath /usr/local/share/elasticsearch/bin/service/lib/wrapper.jar:/usr/local/share/elasticsearch/lib/elasticsearch-0.19.11.jar:/usr/local/share/elasticsearch/lib/elasticsearch-0.19.11.jar:/usr/local/share/elasticsearch/lib/jna-3.3.0.jar:/usr/local/share/elasticsearch/lib/log4j-1.2.17.jar:/usr/local/share/elasticsearch/lib/lucene-analyzers-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-core-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-highlighter-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-memory-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-queries-3.6.1.jar:/usr/local/share/elasticsearch/lib/snappy-java-1.0.4.1.jar:/usr/local/share/elasticsearch/lib/sigar/sigar-1.6.4.jar -Dwrapper.key=b1QUXxfrVfakmb6w -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.disable_console_input=TRUE -Dwrapper.pid=3509 -Dwrapper.version=3.5.14 -Dwrapper.native_library=wrapper -Dwrapper.service=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp org.elasticsearch.bootstrap.ElasticSearchF
jenkins 20372 1 0 08:17 ? 00:00:00 /usr/bin/daemon --name=jenkins --inherit --env=JENKINS_HOME=/mnt/www/jenkins --output=/var/log/jenkins/jenkins.log --pidfile=/var/run/jenkins/jenkins.pid -- /usr/bin/java -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1
jenkins 20373 20372 23 13:20 ? 00:05:51 /usr/bin/java -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1
root 29403 28220 0 13:45 pts/0 00:00:00 grep --color=auto java
How did you expect to set the maximum to a negative value? I think you wanted
-XX:MaxPermSize=128m
-- Update ---
Ok, so you have fixed this, but the build still fails.
Look into the "workspace cleanup plugin", and if it is not installed, install it and activate it. The workspace cleanup plugin will remove evidence of prior builds from the workspace before launch. Odds are that the configuration is stored to file, and then referenced from file immediately prior to launch.
You could move into the workspace directories and grep for the "minus 128" version of the command and alter it by hand, but by using the plugin you also avoid future similar issues.