Daemonizing a Process in Linux
Most of the times when we need to run some Java, Node.js or python program in background, so it could stay running even after you leave console all we do is put “&” in the end of the command.
$java -jar SimpleService.jar &
The problem here is that when you leave the bash shell your process will become “Orphan” and it’s up to the OS if INIT should adopt the process or kill the process.
To fix this we can force the process to be detached from your shell and become child process of INIT by putting nohup in front of command.
$nohup java -jar SimpleService.jar &
It’s all good for testing purposes, but services are supposed to run as “daemons” under some service supervisor. You can find many service supervisors with which you manage your services on Linux and we will cover few of the defaults that come with Linux.
Why do you need it ?
a. auto start/stop the service on startup/shutdown
b. controlling which service should start first
c. controlling which service should stop first is equally important
d. INIT controlled processes directly which provides more options like respawn, post-start, etc..
Ubuntu services using Upstart
Modify the script according to your setup:
$sudo vi /etc/init/java-app.conf
[js]author «nitin»
description «start and stop java-app for Ubuntu (upstart)»
version «1.0»
start on started networking
stop on runlevel [!2345]
# Automatically Respawn a process if fails, try max 5 times in 60 sec then give up
respawn
respawn limit 5 60
# Open files Limit
limit nofile 32768 32768
env APPUSER=»admin»
env APPBIN=»/usr/bin/java»
env APPARGS=»-jar /opt/app/SimpleService.jar»
script
exec su – $APPUSER -c «$APPBIN $APPARGS»
end script
post-stop script
sleep 2
end script[/js]
Check the configuration:
$init-checkconf /etc/init/java-app.conf
Reload New configuration:
$sudo initctl reload-configuration
Check is service is known to Upstart:
$sudo initctl list |grep java
Start the service with:
$sudo start java-app
Note: For any errors look into /var/log/syslog and /var/log/upstart/*
Debian and Ubuntu services using SysVinit
Modify the script according to your setup.
### BEGIN INIT INFO
# Provides: daemon
# Required-Start: $local_fs $network $syslog
# Required-Stop: $local_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Java-app
# Description: Java-app start-stop-daemon – Debian
### END INIT INFO
NAME=»java-app»
PATH=»/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin»
APPDIR=»/opt/app»
APPBIN=»/usr/bin/java»
APPARGS=»-jar /opt/app/SimpleService.jar»
USER=»admin»
GROUP=»admin»
# Include functions
set -e
. /lib/lsb/init-functions
start() printf «Starting ‘$NAME’… »
start-stop-daemon –start –chuid «$USER:$GROUP» –background –make-pidfile –pidfile /var/run/$NAME.pid –chdir «$APPDIR» –exec «$APPBIN» — $APPARGS || true
printf «done\n»
>
#We need this function to ensure the whole process tree will be killed
killtree() local _pid=$1
local _sig=$
for _child in $(ps -o pid –no-headers –ppid $); do
killtree $ $
done
kill -$ $
>
stop() printf «Stopping ‘$NAME’… »
[ -z `cat /var/run/$NAME.pid 2>/dev/null` ] || \
while test -d /proc/$(cat /var/run/$NAME.pid); do
killtree $(cat /var/run/$NAME.pid) 15
sleep 0.5
done
[ -z `cat /var/run/$NAME.pid 2>/dev/null` ] || rm /var/run/$NAME.pid
printf «done\n»
>
status() status_of_proc -p /var/run/$NAME.pid «» $NAME && exit 0 || exit $?
>
Make sure the script is executable:
$chmod +x /etc/init.d/java-app
Enable the service to auto start in runlevel 2345:
$update-rc.d java-app defaults
Start the service with:
$service java-app start
CentOS/Redhat services using SysVinit
Modify the parameter according to your setup:
$sudo vi /etc/init.d/example
[js]#!/bin/sh
#
# example start stop daemon for CentOS (sysvinit)
#
# chkconfig: – 64 36
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 2 3 4 6
# Required-Start:
# description: java-app start stop daemon for CentOS
# processname: java-app
# pidfile: none
# lockfile: /var/lock/subsys/java-app
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ «$NETWORKING» = «no» ] && exit 0
USER=»admin»
APPNAME=»java-app»
APPBIN=»/usr/bin/java»
APPARGS=»-jar /opt/app/SimpleService.jar»
LOGFILE=»/var/log/$APPNAME/error.log»
LOCKFILE=»/var/lock/subsys/$APPNAME»
start() [ -x $prog ] || exit 5
[ -d $LOGPATH ] || mkdir $LOGPATH
[ -f $LOGFILE ] || touch $LOGFILE
echo -n $»Starting $APPNAME: »
daemon –user=$USER «$APPBIN $APPARGS >>$LOGFILE &»
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch $LOCKFILE
return $RETVAL
>
stop() echo -n $»Stopping $APPNAME: »
killproc $APPBIN
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f $LOCKFILE
return $RETVAL
>
Make sure the script is marked as executable:
$sudo chmod +x /etc/init.d/java-app
Enable the service to auto start at runlevels 2345:
$sudo chkconfig java-app on
Start the service with:
$sudo service java-app start
This is how simple it is to daemonize a process. In my next blog, I will talk about more interesting features available in Linux OS.
daemonize(1) — Linux man page
daemonize runs a command as a Unix daemon. As defined in W. Richard Stevens’ 1990 book, Unix Network Programming (Addison-Wesley, 1990), a daemon is ‘a process that executes ‘in the background’ (i.e., without an associated terminal or login shell) either waiting for some event to occur, or waiting to perform some specified task on a periodic basis.’ Upon startup, a typical daemon program will: Close all open file descriptors (especially standard input, standard output and standard error) Change its working directory to the root filesystem, to ensure that it doesn’t tie up another filesystem and prevent it from being unmounted Reset its umask value Run in the background (i.e., fork) Disassociate from its process group (usually a shell), to insulate itself from signals (such as HUP) sent to the process group Ignore all terminal I/O signals Disassociate from the control terminal (and take steps not to reacquire one) Handle any SIGCLD signals
Most programs that are designed to be run as daemons do that work for themselves. However, you’ll occasionally run across one that does not. When you must run a daemon program that does not properly make itself into a true Unix daemon, you can use daemonize to force it to run as a true daemon.
Options
-a Append to the output files, rather than overwriting them (which is the default). Only applicable if -e and/or -o are specified. -c directory Specifies the directory to which to change before running the program. Defaults to «/». The choice for this option is important. The file system containing the daemon’s working directory cannot be unmounted while the daemon is running. That’s why most daemons are careful to use a working directory on the root file system. -e stderr Redirect standard error to the specified file, instead of «/dev/null».
Warning: Be careful where you redirect the output! The file system containing the open file cannot be unmounted as long as the file is open. For best results, make sure that this output file is on the same file system as the daemon’s working directory. (See the -c option.) -E name=value Add an environment variable to the environment the daemon will see. The parameter must be of the form name=value. This parameter may be specified multiple times. -o stdout Redirect standard output to the specified file, instead of «/dev/null».
Warning: Be careful where you redirect the output! The file system containing the open file cannot be unmounted as long as the file is open. For best results, make sure that this output file is on the same file system as the daemon’s working directory. (See the -c option.) -p pidfile Causes daemonize to write the numeric process ID (PID) of the running daemon to the specified file. This option is useful when the program being daemonized doesn’t create its own PID file. -l lockfile Single-instance checking. Causes daemonize to ensure that no more than one instance of the daemon is running by placing an exclusive lock on given lockfile. If another process already has a lock on the lockfile, daemonize exits.
It is possible to use the pidfile as the lock file (e.g., «-p /var/run/foo -l /var/run/foo»), though typical daemons use separate files.
NOTE: If the executed program decides to close all file descriptors, the single-instance locking will not work, since the lock depends on an open file descriptor. (The operating system kernel removes the lock once the process holding the lock closes the file or exits.) Normal processes that do not daemonize themselves do not usually close all file descriptors. -u user Run the program as the specified user. This option only works if daemonize is invoked by the superuser. Note: For obvious reasons, it’s very dangerous to install daemonize as a setuid-to-root executable. For that reason, daemonize will refuse to run if it detects that it has been installed that way. -v Cause daemonize to write verbose messages to standard error, telling what it’s doing as it daemonizes the program.
Notes
If the host operating system provides the daemon(3) library routine, daemonize will use it. Otherwise, daemonize uses its own version of daemon(3). This choice is made at compile time. (BSD 4.4-derived operating systems tend to provide their own daemon(3) routine.)
FreeBSD 5.0 introduced a daemon(1) command that is similar to, but less functional, than daemonize.
License
This program released under a BSD-style license. For more details, consult the LICENSE file accompanying the source distribution, or visit «http://software.clapper.org/daemonize/LICENSE».
See Also
daemon(3), setsid(2), flock(2)
Author
Brian M. Clapper, bmc clapper org
Contributors
Support for the -e and -o options is based on a patch submitted by Tim Starling (tstarling wikimedia org).
Support for the -l option is based on a patch submitted by Yakov Lerner (iler.ml gmail com).
Daemonize a process in shell?
If I am corrrect, the command is the same as «nohup and background a process». But isn’t a daemon more than a nohupped and background process? What steps are missing here to daemonize a process? For example, isn’t changing the parent process necessary when daemonizing a process? If yes, how do you do that in bash? I am still trying to understand a related reply https://unix.stackexchange.com/a/177361/674. What other steps and conditions? See my related question https://stackoverflow.com/q/35705451/156458
depends on your definition of daemons. If you merely mean running in the background detached from a terminal then yes you are running firefox as a daemon. «standard» daemons, however, typically are not run by users, have an init script and logging, and typically some sort of security, often apparmor or selinux depending on if you are running Ubuntu or Fedora (or similar). See linfo.org/daemon.html .
Have a look at start-stop-daemon in Debian ; I will leave here a related thread from stack overflow stackoverflow.com/questions/16139940/… which is more interesting than the raw man page
2 Answers 2
In a Unix environment, the parent process of a daemon is often, but not always, the init process. A daemon is usually either created by a process forking a child process and then immediately exiting, thus causing init to adopt the child process, or by the init process directly launching the daemon. In addition, a daemon launched by forking and exiting typically must perform other operations, such as dissociating the process from any controlling terminal (tty). Such procedures are often implemented in various convenience routines such as daemon(3) in Unix.
Read the manpage of the daemon function.
Running a background command from a shell that immediately exits results in the process’s PPID becoming 1. Easy to test:
# bash -c 'nohup sleep 10000 &>/dev/null & jobs -p %1' 1936 # ps -p 1936 PID PPID PGID WINPID TTY UID STIME COMMAND 1936 1 9104 9552 cons0 1009 17:28:12 /usr/bin/sleep As you can see, the process is owned by PID 1, but still associated with a TTY. If I log out from this login shell, then log in again, and do ps again, the TTY becomes ? .
Using setsid (part of util-linux ):
# bash -c 'cd /; setsid sleep 10000 /dev/null & jobs -p %1' 9864 # ps -p 9864 PID PPID PGID WINPID TTY UID STIME COMMAND 9864 1 9864 6632 ? 1009 17:40:35 /usr/bin/sleep I think you don’t even have to redirect stdin, stdout and stderr.