Related
I have written a Java server application that runs on a standard virtual hosted Linux solution. The application runs all the time listening for socket connections and creating new handlers for them. It is a server side implementation to a client-server application.
The way I start it is by including it in the start up rc.local script of the server. However once started I do not know how to access it to stop it and if I want to install an update, so I have to restart the server in order to restart the application.
On a windows PC, for this type of application I might create a windows service and then I can stop and start it as I want. Is there anything like that on a Linux box so that if I start this application I can stop it and restart it without doing a complete restart of the server.
My application is called WebServer.exe. It is started on server startup by including it in my rc.local as such:
java -jar /var/www/vhosts/myweb.com/phpserv/WebServer.jar &
I am a bit of a noob at Linux so any example would be appreciated with any posts. However I do have SSH, and full FTP access to the box to install any updates as well as access to a Plesk panel.
I wrote another simple wrapper here:
#!/bin/sh
SERVICE_NAME=MyService
PATH_TO_JAR=/usr/local/MyProject/MyJar.jar
PID_PATH_NAME=/tmp/MyService-pid
case $1 in
start)
echo "Starting $SERVICE_NAME ..."
if [ ! -f $PID_PATH_NAME ]; then
nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null &
echo $! > $PID_PATH_NAME
echo "$SERVICE_NAME started ..."
else
echo "$SERVICE_NAME is already running ..."
fi
;;
stop)
if [ -f $PID_PATH_NAME ]; then
PID=$(cat $PID_PATH_NAME);
echo "$SERVICE_NAME stoping ..."
kill $PID;
echo "$SERVICE_NAME stopped ..."
rm $PID_PATH_NAME
else
echo "$SERVICE_NAME is not running ..."
fi
;;
restart)
if [ -f $PID_PATH_NAME ]; then
PID=$(cat $PID_PATH_NAME);
echo "$SERVICE_NAME stopping ...";
kill $PID;
echo "$SERVICE_NAME stopped ...";
rm $PID_PATH_NAME
echo "$SERVICE_NAME starting ..."
nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null &
echo $! > $PID_PATH_NAME
echo "$SERVICE_NAME started ..."
else
echo "$SERVICE_NAME is not running ..."
fi
;;
esac
You can follow a full tutorial for init.d here and for systemd (ubuntu 16+) here
If you need the output log replace the 2
nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null &
lines for
nohup java -jar $PATH_TO_JAR >> myService.out 2>&1&
A simple solution is to create a script start.sh that runs Java through nohup and then stores the PID to a file:
nohup java -jar myapplication.jar > log.txt 2> errors.txt < /dev/null &
PID=$!
echo $PID > pid.txt
Then your stop script stop.sh would read the PID from the file and kill the application:
PID=$(cat pid.txt)
kill $PID
Of course I've left out some details, like checking whether the process exists and removing pid.txt if you're done.
Linux service init script are stored into /etc/init.d. You can copy and customize /etc/init.d/skeleton file, and then call
service [yourservice] start|stop|restart
see http://www.ralfebert.de/blog/java/debian_daemon/. Its for Debian (so, Ubuntu as well) but fit more distribution.
Maybe not the best dev-ops solution, but good for the general use of a server for a lan party or similar.
Use screen to run your server in and then detach before logging out, this will keep the process running, you can then re-attach at any point.
Workflow:
Start a screen: screen
Start your server: java -jar minecraft-server.jar
Detach by pressing: Ctl-a, d
Re-attach: screen -r
More info here: https://www.gnu.org/software/screen/manual/screen.html
Another alternative, which is also quite popular is the Java Service Wrapper. This is also quite popular around the OSS community.
Referring to Spring Boot application as a Service as well, I would go for the systemd version, since it's the easiest, least verbose, and best integrated into modern distros (and even the not-so-modern ones like CentOS 7.x).
The easiest way is to use supervisord. Please see full details here: http://supervisord.org/
More info:
https://askubuntu.com/questions/779830/running-an-executable-jar-file-when-the-system-starts/852485#852485
https://www.digitalocean.com/community/tutorials/how-to-install-and-manage-supervisor-on-ubuntu-and-debian-vps
Here is a sample shell script (make sure you replace the MATH name with the name of the your application):
#!/bin/bash
### BEGIN INIT INFO
# Provides: MATH
# Required-Start: $java
# Required-Stop: $java
# Short-Description: Start and stop MATH service.
# Description: -
# Date-Creation: -
# Date-Last-Modification: -
# Author: -
### END INIT INFO
# Variables
PGREP=/usr/bin/pgrep
JAVA=/usr/bin/java
ZERO=0
# Start the MATH
start() {
echo "Starting MATH..."
#Verify if the service is running
$PGREP -f MATH > /dev/null
VERIFIER=$?
if [ $ZERO = $VERIFIER ]
then
echo "The service is already running"
else
#Run the jar file MATH service
$JAVA -jar /opt/MATH/MATH.jar > /dev/null 2>&1 &
#sleep time before the service verification
sleep 10
#Verify if the service is running
$PGREP -f MATH > /dev/null
VERIFIER=$?
if [ $ZERO = $VERIFIER ]
then
echo "Service was successfully started"
else
echo "Failed to start service"
fi
fi
echo
}
# Stop the MATH
stop() {
echo "Stopping MATH..."
#Verify if the service is running
$PGREP -f MATH > /dev/null
VERIFIER=$?
if [ $ZERO = $VERIFIER ]
then
#Kill the pid of java with the service name
kill -9 $($PGREP -f MATH)
#Sleep time before the service verification
sleep 10
#Verify if the service is running
$PGREP -f MATH > /dev/null
VERIFIER=$?
if [ $ZERO = $VERIFIER ]
then
echo "Failed to stop service"
else
echo "Service was successfully stopped"
fi
else
echo "The service is already stopped"
fi
echo
}
# Verify the status of MATH
status() {
echo "Checking status of MATH..."
#Verify if the service is running
$PGREP -f MATH > /dev/null
VERIFIER=$?
if [ $ZERO = $VERIFIER ]
then
echo "Service is running"
else
echo "Service is stopped"
fi
echo
}
# Main logic
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status
;;
restart|reload)
stop
start
;;
*)
echo $"Usage: $0 {start|stop|status|restart|reload}"
exit 1
esac
exit 0
From Spring Boot application as a Service, I can recommend the Python-based supervisord application. See that stack overflow question for more information. It's really straightforward to set up.
Other answers do a good job giving custom scripts and setups depending on your platform. In addition to those, here are the mature, special purpose programs that I know of:
JSW from TanukiSoftware
YAJSW is an open source clone from the above. It is written in Java, and it is a nanny process that manages the child process (your code) according to configurations. Works on windows / linux.
JSVC is a native application. Its also a nanny process, but it invokes your child application through the JNI, rather than as a subprocess.
You can use Thrift server or JMX to communicate with your Java service.
From Spring Boot Reference Guide
Installation as an init.d service (System V)
Simply symlink the jar to init.d to support the standard start, stop, restart and status commands.
Assuming that you have a Spring Boot application installed in /var/myapp, to install a Spring Boot application as an init.d service simply create a symlink:
$ sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp
Once installed, you can start and stop the service in the usual way. For example, on a Debian based system:
$ service myapp start
If your application fails to start, check the log file written to /var/log/<appname>.log for errors.
Continue reading to know how to secure a deployed service.
After doing as written I've discovered that my service fails to start with this error message in logs: start-stop-daemon: unrecognized option --no-close. And I've managed to fix it by creating a config file /var/myapp/myapp.conf with the following content
USE_START_STOP_DAEMON=false
It is possible to run the war as a Linux service, and you may want to force in your pom.xml file before packaging, as some distros may not recognize in auto mode. To do it, add the following property inside of spring-boot-maven-plugin plugin.
<embeddedLaunchScriptProperties>
<mode>service</mode>
</embeddedLaunchScriptProperties>
Next, setup your init.d with:
ln -s myapp.war /etc/init.d/myapp
and you will be able to run
service myapp start|stop|restart
There are many other options that you can find in Spring Boot documentation, including Windows service.
Im having Netty java application and I want to run it as a service with systemd. Unfortunately application stops no matter of what Type I'm using. At the end I've wrapped java start in screen. Here are the config files:
service
[Unit]
Description=Netty service
After=network.target
[Service]
User=user
Type=forking
WorkingDirectory=/home/user/app
ExecStart=/home/user/app/start.sh
TimeoutStopSec=10
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
start
#!/bin/sh
/usr/bin/screen -L -dmS netty_app java -cp app.jar classPath
from that point you can use systemctl [start|stop|status] service.
To run Java code as daemon (service) you can write JNI based stub.
http://jnicookbook.owsiak.org/recipe-no-022/
for a sample code that is based on JNI. In this case you daemonize the code that was started as Java and main loop is executed in C. But it is also possible to put main, daemon's, service loop inside Java.
https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo029
Have fun with JNI!
However once started I don't know how to access it to stop it
You can write a simple stop script that greps for your java process, extracts the PID and calls kill on it. It's not fancy, but it's straight forward.
Something like that may be of help as a start:
#!/bin/bash
PID = ps ax | grep "name of your app" | cut -d ' ' -f 1
kill $PID
I connect to the linux server via putty SSH. I tried to run it as a background process like this:
$ node server.js &
However, after 2.5 hrs the terminal becomes inactive and the process dies. Is there anyway I can keep the process alive even with the terminal disconnected?
Edit 1
Actually, I tried nohup, but as soon as I close the Putty SSH terminal or unplug my internet, the server process stops right away.
Is there anything I have to do in Putty?
Edit 2 (on Feb, 2012)
There is a node.js module, forever. It will run node.js server as daemon service.
nohup node server.js > /dev/null 2>&1 &
nohup means: Do not terminate this process even when the stty is cut
off.
> /dev/null means: stdout goes to /dev/null (which is a dummy
device that does not record any output).
2>&1 means: stderr also goes to the stdout (which is already redirected to /dev/null). You may replace &1 with a file path to keep a log of errors, e.g.: 2>/tmp/myLog
& at the end means: run this command as a background task.
Simple solution (if you are not interested in coming back to the process, just want it to keep running):
nohup node server.js &
There's also the jobs command to see an indexed list of those backgrounded processes. And you can kill a backgrounded process by running kill %1 or kill %2 with the number being the index of the process.
Powerful solution (allows you to reconnect to the process if it is interactive):
screen
You can then detach by pressing Ctrl+a+d and then attach back by running screen -r
Also consider the newer alternative to screen, tmux.
You really should try to use screen. It is a bit more complicated than just doing nohup long_running &, but understanding screen once you never come back again.
Start your screen session at first:
user#host:~$ screen
Run anything you want:
wget http://mirror.yandex.ru/centos/4.6/isos/i386/CentOS-4.6-i386-binDVD.iso
Press ctrl+A and then d. Done. Your session keeps going on in background.
You can list all sessions by screen -ls, and attach to some by screen -r 20673.pts-0.srv command, where 0673.pts-0.srv is an entry list.
This is an old question, but is high ranked on Google. I almost can't believe on the highest voted answers, because running a node.js process inside a screen session, with the & or even with the nohup flag -- all of them -- are just workarounds.
Specially the screen/tmux solution, which should really be considered an amateur solution. Screen and Tmux are not meant to keep processes running, but for multiplexing terminal sessions. It's fine, when you are running a script on your server and want to disconnect. But for a node.js server your don't want your process to be attached to a terminal session. This is too fragile. To keep things running you need to daemonize the process!
There are plenty of good tools to do that.
PM2: http://pm2.keymetrics.io/
# basic usage
$ npm install pm2 -g
$ pm2 start server.js
# you can even define how many processes you want in cluster mode:
$ pm2 start server.js -i 4
# you can start various processes, with complex startup settings
# using an ecosystem.json file (with env variables, custom args, etc):
$ pm2 start ecosystem.json
One big advantage I see in favor of PM2 is that it can generate the system startup script to make the process persist between restarts:
$ pm2 startup [platform]
Where platform can be ubuntu|centos|redhat|gentoo|systemd|darwin|amazon.
forever.js: https://github.com/foreverjs/forever
# basic usage
$ npm install forever -g
$ forever start app.js
# you can run from a json configuration as well, for
# more complex environments or multi-apps
$ forever start development.json
Init scripts:
I'm not go into detail about how to write a init script, because I'm not an expert in this subject and it'd be too long for this answer, but basically they are simple shell scripts, triggered by OS events. You can read more about this here
Docker:
Just run your server in a Docker container with -d option and, voilá, you have a daemonized node.js server!
Here is a sample Dockerfile (from node.js official guide):
FROM node:argon
# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
# Install app dependencies
COPY package.json /usr/src/app/
RUN npm install
# Bundle app source
COPY . /usr/src/app
EXPOSE 8080
CMD [ "npm", "start" ]
Then build your image and run your container:
$ docker build -t <your username>/node-web-app .
$ docker run -p 49160:8080 -d <your username>/node-web-app
Always use the proper tool for the job. It'll save you a lot of headaches and over hours!
another solution disown the job
$ nohup node server.js &
[1] 1711
$ disown -h %1
nohup will allow the program to continue even after the terminal dies. I have actually had situations where nohup prevents the SSH session from terminating correctly, so you should redirect input as well:
$ nohup node server.js </dev/null &
Depending on how nohup is configured, you may also need to redirect standard output and standard error to files.
Nohup and screen offer great light solutions to running Node.js in the background. Node.js process manager (PM2) is a handy tool for deployment. Install it with npm globally on your system:
npm install pm2 -g
to run a Node.js app as a daemon:
pm2 start app.js
You can optionally link it to Keymetrics.io a monitoring SAAS made by Unitech.
$ disown node server.js &
It will remove command from active task list and send the command to background
I have this function in my shell rc file, based on #Yoichi's answer:
nohup-template () {
[[ "$1" = "" ]] && echo "Example usage:\nnohup-template urxvtd" && return 0
nohup "$1" > /dev/null 2>&1 &
}
You can use it this way:
nohup-template "command you would execute here"
Have you read about the nohup command?
To run command as a system service on debian with sysv init:
Copy skeleton script and adapt it for your needs, probably all you have to do is to set some variables. Your script will inherit fine defaults from /lib/init/init-d-script, if something does not fits your needs - override it in your script. If something goes wrong you can see details in source /lib/init/init-d-script. Mandatory vars are DAEMON and NAME. Script will use start-stop-daemon to run your command, in START_ARGS you can define additional parameters of start-stop-daemon to use.
cp /etc/init.d/skeleton /etc/init.d/myservice
chmod +x /etc/init.d/myservice
nano /etc/init.d/myservice
/etc/init.d/myservice start
/etc/init.d/myservice stop
That is how I run some python stuff for my wikimedia wiki:
...
DESC="mediawiki articles converter"
DAEMON='/home/mss/pp/bin/nslave'
DAEMON_ARGS='--cachedir /home/mss/cache/'
NAME='nslave'
PIDFILE='/var/run/nslave.pid'
START_ARGS='--background --make-pidfile --remove-pidfile --chuid mss --chdir /home/mss/pp/bin'
export PATH="/home/mss/pp/bin:$PATH"
do_stop_cmd() {
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
$STOP_ARGS \
${PIDFILE:+--pidfile ${PIDFILE}} --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
rm -f $PIDFILE
return $RETVAL
}
Besides setting vars I had to override do_stop_cmd because of python substitutes the executable, so service did not stop properly.
Apart from cool solutions above I'd mention also about supervisord and monit tools which allow to start process, monitor its presence and start it if it died. With 'monit' you can also run some active checks like check if process responds for http request
For Ubuntu i use this:
(exec PROG_SH &> /dev/null &)
regards
Try this for a simple solution
cmd & exit
I have a java app on my (Ubuntu) server. If I do this, then it starts correctly:
/usr/bin/java -cp /home/jenkins/veta/lily.jar com.sugarapp.lily.Main
but I don't know how to get its PID. I don't know how to stop it with an init.d script.
I have a different app, written in Clojure, and for it I was able to write an init.d script that works great. So I tried to refashion that init.d script for my Java app, and this is what I got:
WORK_DIR="/home/jenkins/veta"
NAME="lily"
JAR="lily.jar"
USER="jenkins"
DAEMON="/usr/bin/java"
DAEMON_ARGS=" -cp /home/jenkins/veta/lily.jar com.sugarapp.lily.Main"
start () {
echo "Starting lily..."
if [ ! -f $WORK_DIR/lily.pid ]; then
/sbin/start-stop-daemon --start --verbose --background --chdir $WORK_DIR --exec $DAEMON --pidfile $WORK_DIR/lily.pid --chuid "$USER" --make-pidfile -- $DAEMON_ARGS
else
echo "lily is already running..."
fi
}
stop () {
echo "Stopping lily..."
/sbin/start-stop-daemon --stop --exec $DAEMON --pidfile $WORK_DIR/lily.pid
rm $WORK_DIR/lily.pid
}
But this doesn't work. Although the PID in $WORK_DIR/lily.pid changes every time I run the script, no process with that PID ever seems to run. If I try:
ps aux | grep java
I don't see this app, nor if I try using the PID.
So is there a way I can use the first command, but somehow capture the PID, so I can store it for later?
I just want a reliable way to stop and start this app. That can be by PID or some other factor. I'm open to suggestions.
UPDATE:
Maybe my question is unclear? Something like jps or ps will give me too many answers. If I do something like "ps aux | grep java" I'll see that there are 5 different java apps running on the server. The start-stop-daemon won't know which PID belongs to this particular app, nor can I figure out what I should feed into my init.d script.
If your system has jdk installed there is an utility called jps which resides in jdk/bin. It will display the list of running java process. Make use of it.
If jdk is not installed in your machine then you have to grep the java process from ps -eaf command.
If you want the pid from the command line, this might work:
myCommand & echo $!
Which I copied from the accepted response to a very similar topic in ServerFault: https://serverfault.com/a/205504
At the moment I have to go to /usr/java/apache-solr-1.4.0/example and then do:
java -jar start.jar
How do I get this to start automatically on boot?
I'm on a shared Linux server.
As you're on a shared Linux box, you'll have to ask the system administrator to do the following, probably.
Create a startup script in /etc/init.d/solr.
Copy this code, my Solr startup script, into that file:
#!/bin/sh
# Prerequisites:
# 1. Solr needs to be installed at /usr/local/solr/example
# 2. daemon needs to be installed
# 3. Script needs to be executed by root
# This script will launch Solr in a mode that will automatically respawn if it
# crashes. Output will be sent to /var/log/solr/solr.log. A PID file will be
# created in the standard location.
start () {
echo -n "Starting solr..."
# Start daemon
daemon --chdir='/usr/local/solr/example' --command "java -jar start.jar" --respawn --output=/var/log/solr/solr.log --name=solr --verbose
RETVAL=$?
if [ $RETVAL = 0 ]
then
echo "done."
else
echo "failed. See error code for more information."
fi
return $RETVAL
}
stop () {
# Stop daemon
echo -n "Stopping solr..."
daemon --stop --name=solr --verbose
RETVAL=$?
if [ $RETVAL = 0 ]
then
echo "Done."
else
echo "Failed. See error code for more information."
fi
return $RETVAL
}
restart () {
daemon --restart --name=solr --verbose
}
status () {
# Report on the status of the daemon
daemon --running --verbose --name=solr
return $?
}
case "$1" in
start)
start
;;
status)
status
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: solr {start|status|stop|restart}"
exit 3
;;
esac
exit $RETVAL
Then run:
chkconfig --add solr
Or (on Ubuntu):
update-rc.d solr defaults
... or, if your Linux distribution doesn't have chkconfig (or update-rc.d), link /etc/init.d/solr to /etc/rc3.d/S99solr and /etc/rc5.d/S99solr and /etc/rc3.d/K01solr and /etc/rc5.d/K01solr:
% ln -s /etc/init.d/solr /etc/rc3.d/S99solr
% ln -s /etc/init.d/solr /etc/rc5.d/S99solr
% ln -s /etc/init.d/solr /etc/rc3.d/K01solr
% ln -s /etc/init.d/solr /etc/rc5.d/K01solr
Now on reboot Solr will startup in run levels 3 and 5 (console with network & full GUI).
To start solr manually run:
% /etc/init.d/solr start
If you have root access to your machine, there are a number of ways to do this based on your system's initialization flow (init scripts, systemd, etc.)
But if you don't have root, cron has a clean and consistent way to execute programs upon reboot.
First, find out where java is located on your machine. The command below will tell you where it is:
$ which java
Then, stick the following code into a shell script, replacing the java path below (/usr/bin) with the path you got from the above command.
#!/bin/bash
cd /usr/java/apache-solr-1.4.0/example
/usr/bin/java -jar start.jar
You can save this script in some location (e.g., $HOME) as start.sh. Give it world execute permission (to simplify) by running the following command:
$ chmod og+x start.sh
Now, test the script and ensure that it works correctly from the command line.
$ ./start.sh
If all works well, you need to add it to one of your machine's startup scripts. The simplest way to do this is to add the following line to the end of /etc/rc.local.
# ... snip contents of rc.local ...
# Start Solr upon boot.
/home/somedir/start.sh
Alternatively, if you don't have permission to edit rc.local, then you can add it to your user crontab as so. First type the following on the commandline:
$ crontab -e
This will bring up an editor. Add the following line to it:
#reboot /home/somedir/start.sh
If your Linux system supports it (which it usually does), this will ensure that your script is run upon startup.
If I don't have any typos above, it should work out well for you. Let me know how it goes.
Adding the following lines to my /etc/init.d/solr file works to support Red Hat Linux (I copied them from /etc/init.d/mysql after reading comments by others here).
# Comments to support chkconfig on Red Hat Linux
# chkconfig: 2345 64 36
# Description: A very fast and reliable search engine.
There are three steps that you need to do here:
Create the script, make it executable, and put it in the right place.
Make the script start up properly on reboot.
Bonus: Set up a logrotation script so logs don't get out of control.
For number one, I've tuned supermagic's script from above. It was OK, but had a number of typos, lacked some functionality (status, restart), didn't use the daemon utility very effectively.
Here's my version of the script (make sure you have daemon installed for it to work):
#!/bin/sh
# Prerequisites:
# 1. Solr needs to be installed at /usr/local/solr/example
# 2. daemon needs to be installed
# 3. Script needs to be executed by root
# This script will launch Solr in a mode that will automatically respawn if it
# crashes. Output will be sent to /var/log/solr/solr.log. A pid file will be
# created in the standard location.
start () {
echo -n "Starting solr..."
# start daemon
daemon --chdir='/usr/local/solr/example' --command "java -jar start.jar" --respawn --output=/var/log/solr/solr.log --name=solr --verbose
RETVAL=$?
if [ $RETVAL = 0 ]
then
echo "done."
else
echo "failed. See error code for more information."
fi
return $RETVAL
}
stop () {
# stop daemon
echo -n "Stopping solr..."
daemon --stop --name=solr --verbose
RETVAL=$?
if [ $RETVAL = 0 ]
then
echo "done."
else
echo "failed. See error code for more information."
fi
return $RETVAL
}
restart () {
daemon --restart --name=solr --verbose
}
status () {
# report on the status of the daemon
daemon --running --verbose --name=solr
return $?
}
case "$1" in
start)
start
;;
status)
status
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: solr {start|status|stop|restart}"
exit 3
;;
esac
exit $RETVAL
Place this script at /etc/init.d/solr, make it executable, and you should be good with step one. You can now start/stop/restart/status a solr daemon with /etc/init.d/solr start|stop|restart|status
For step two, run the following on an Ubuntu machine (don't know about Redhat):
update-rc.d solr defaults
Once this is done, you're in pretty good shape, but you probably want to rotate the logs properly at some point, so here's a good config for the logs:
/var/log/solr/*.log {
weekly
rotate 12
compress
delaycompress
create 640 root root
postrotate
/etc/init.d/solr restart
endscript
}
Place that file in /etc/logrotate.d/solr, and you should be good to go, assuming logrotate is running (it usually is).
I answered this question once already, but that answer was for operating systems that used SysV and this one is for newer operating systems that are increasingly using systemd.
As in my other answer, there are three things you'll need to do here:
Create the script and put it in the right place.
Make the script start up properly on reboot.
Bonus: Make systemd logs persistent.
1. Creating the script and putting it in the right place
Here's a systemd unit file that you can use (these replace the SysV init files). Name it solr.service.
[Unit]
Description=Apache Solr
After=syslog.target network.target remote-fs.target nss-lookup.target
[Service]
Type=simple
Environment="XMX=2G"
WorkingDirectory=/usr/local/solr/example
ExecStart=/usr/bin/java -jar -server -Xmx${XMX} start.jar
Restart=on-failure
LimitNOFILE=10000
[Install]
WantedBy=multi-user.target
Note that there's a configuration in there for Solr's memory. You'll probably want to tweak that to your own purposes. If you have a number of variables you're passing to systemd, you can do that with the EnvironmentFile directive.
More documentation for these files is here.
2. Make the script startup properly at boot
This is fairly simple, but there are rules. To make it start at boot, put the file in /etc/systemd/system/solr.service. You cannot use a symlink in this directory, do not try.
Once that's in there, you can enable the daemon to run at boot with:
sudo systemctl enable solr
And you can start, stop, status it with:
sudo systemctl {start|stop|status} solr
3. Making systemd logs persistent
By default, systemd logs are not persistent and they are lost whenever you reboot the system. If that's not what you desire, you can make them persistent by creating a directory:
sudo mkdir -p /var/log/journal/
And then restarting the systemd journaling daemon:
sudo systemctl restart systemd-journald
Once that's complete, systemd's journaling daemon will receive all the stdout and stderr that Solr creates and it will get stored in a binary format under /var/log/journal/.
The way systemd handles logging is pretty neat and is worth studying if you're not familiar with it. In the meantime, just know that to read your log entries you'll need to use a new tool called journalctl. For example, this will follow your solr logs:
journalctl -u solr -f
And there are also flags for doing date-based filtering and things like that.
3.1 Tweaking the log files
Bonus section! If you want to tweak the log files, you can read all about it in the documentation here, but the defaults are actually very safe and sane (logs are compressed by default, can't grow too large, are rate limited, and are written to disk in batches).
Follow supermagic's comments, then follow this
http://codingrecipes.com/service-x-does-not-support-chkconfig
He says,
1 – Copy your script into /etc/init.d folder
2 – cd /etc/init.d
3 – chmod +x myscript
4 – Add these lines, including #, right after #!/bin/bash or #!/bin/sh:
# chkconfig: 2345 95 20
# description: Some description
# What your script does (not sure if this is necessary though)
# processname: myscript
Then you can do
chkconfig --add myscript
init.d/solr script that's tested on Centos 6/Amazon Linux. It wraps solr's native CLI.
#!/bin/bash
# description: Starts and stops Solr production
PIDFILE=/var/run/solr.pid
SOLR_HOME=/usr/share/solr
START_COMMAND="$SOLR_HOME/bin/solr start -p 8984 -noprompt -m 1g"
NAME="Solr"
start() {
echo "Starting $NAME"
if [ -f $PIDFILE ]; then
echo -n "$PIDFILE exists. $NAME may be running."
else
str=`$START_COMMAND`
pid=`echo $str | grep -o "pid=[0-9]*" | grep -o "[0-9]*"`
if [ "$pid" == "" ];
then
echo "[FATAL ERROR] Failed to extract pid. Exiting!"
exit 1
fi
echo $pid > $PIDFILE
fi
return 0
}
case "$1" in
start)
start
;;
stop)
echo "Stopping $NAME .."
$SOLR_HOME/bin/solr stop
rm -f $PIDFILE
;;
status)
$SOLR_HOME/bin/solr status
;;
restart)
$0 stop
#sleep 2
$0 start
;;
*)
echo "Usage: $0 (start | stop | restart | status)"
exit 1
;;
esac
exit $?
Check
man 5 crontab
See if #reboot is supported on the Linux system you are using.
At boot, our server needs to start Teamspeak and a teamspeak bot. The first part works, teamspeak always starts, never an issue.
However, the teamspeak bot never starts, nor is the Screen session created.
rc.local file displayed below.
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
sleep 2
su teamspeak -c 'screen -d -m -S ts3 /home/teamspeak/teamspeak/ts3server_minimal_runscript.sh inifile=ts3server.ini'
sleep 2
su teamspeak -c 'screen -d -m -S tsbot /usr/bin/java -jar /home/teamspeak/jts3servermod/JTS3ServerMod.jar'
exit 0
As stated, teamspeak starts the way it should, within it's own screen session. The .jar file does not however and the screen session isn't there either.
Can someone tell me where I made a mistake?
You shouldn't run scripts like that. I'm not sure what's wrong but I would definitely write an sysv/upstart script to do that. the second answer is what you should use