Configure Tomcat as a deamon on Linux

Since I keep on forgetting how to do this I decided to put this on my blog to make it easier for me and other people that have the same issue as me. It's pretty simple actually but yesterday I caught myself forgetting how it needs to be done. Basically you need to follow to following steps to successfully.

Step 1 - Creating startup deamon file

You can take the following file and adjust it accordingly. You have to create this file in /etc/init.d/.



#Jenkins startup script
#!/bin/sh -e
#Jenkins startup script
#chkconfig: 2345 80 05
#description: Jenkins CI

# Define some variables
# Name of app
APP=Jenkins
# Name of the user to run as
USER=tomcat
# Location of application's bin directory
BASE=/var/tomcat/instances/jenkins
# Location of Java JDK
export JAVA_HOME=/opt/java/jdk1.6.0_11

case "$1" in
# Start command
start)
echo "Starting $APP"
/bin/su -m $USER -c "cd $BASE/logs && $BASE/bin/startup.sh &> /dev/null"
;;
# Stop command
stop)
echo "Stopping $APP"
/bin/su -m $USER -c "$BASE/bin/shutdown.sh &> /dev/null"
echo "$APP stopped successfully"
;;
# Restart command
restart)
$0 stop
sleep 5
$0 start
;;
*)
echo "Usage: /etc/init.d/$APP {start|restart|stop}"
exit 1
;;
esac

exit 0


Step 2 - Register your deamon

To register your deamon you can use chkconfig. This will make sure your deamon will be started up on boot and enables you to use the following command to start and stop your tomcat instance.

To start:

service jenkins start


To stop:

service jenkins stop


To do the magic you should execute the following command:

chkconfig jenkins --add


Now your done :-)

Comments

Post a Comment

Popular posts from this blog

Fastest XML parser

In most applications you need to do some XML parsing to either provide XML to external systems or parse XML from external systems or of course both. Since the systems I work on use a lot of XML and they need to be as fast as possible I did some tests on several XML parsers. I tested the following parsers/XML frameworks: JDom Piccolo StaxMate XStream JAXB 2.1 All parsers were tested in isolation with the following parameters: 25 threads running simultaniously Every thread calls the parser 100 times The results are as follows. JDom Avg. parsing time: 325.24 ms Avg. memory usage: 307 KB Piccolo Avg. parsing time: 88.08 ms Avg. memory usage: 454 KB StaxMate Avg. parsing time: 96.16 ms Avg. memory usage: 203 KB XStream Avg. parsing time: 77.04 ms Avg. memory usage: 319 KB Jaxb 2.1 Avg. parsing time: 1778.12 ms Avg. memory usage: 618 KB As you can see XStream is the fastest one of them all. The total ranking of the parsers you can find below: XStream Piccolo StaxMate JDom JAXB 2.1
Read more

Tomcat behind Apache HTTP server using Spring Security

Since I have been struggling with applications not working properly behind Apache HTTP server that use Spring Security I dedicated this blog to this issue. When you develop an application using Spring security this works fine when just running on a Tomcat server e.g. http://localhost:8080/app-context/. The problems start when you want to setup your environment properly by adding an Apache HTTP server in front of it using proxy AJP. You would start by adding the following to your apache config file: ProxyPass /app-context/ ajp://localhost:8009/app-context/ This works fine when trying to go to http://servername/app-context/ but when you try to login you will be redirected back to the login page everytime. To avoid this behavior you need to add the following line to your Apache configuration: ProxyPass /app-context/j_spring_security_check ajp://localhost:8009/app-context/j_spring_security_check For some reason it doesn't work without this line which seems weird to me since you basical
Read more

Cargo-itest open source project

I recently started an open source project called cargo-itest. This was started up because when I worked on several projects I needed to create integration tests for them which all had similarities. I was previously doing it with the maven2 cargo plug-in but wasn't really fond of it because it most of the times didn't work and when it worked it stopped working after editing the configuration. In other words it was very unstable. This initiated me to start to use the java API of Cargo instead of the maven plugin. By using the java API it already removes the dependency from your build system in this case Maven. Having no dependency on the build system gives you a couple of advantages: You can run it in any IDE that supports JUnit. You can switch easily to another build system without changing your tests and test configuration. These are general advantages of just using the API but also part of using my open source project cargo-itest. This project enables you to easily start creat
Read more