2

I've written a custom python daemon that runs as a service via an init.d script on ubuntu 14.04. Starting the service works fine, but when I try to do "service monitor stop", the daemon is not terminated. I'm using pyinotify to daemonize a file watcher for changes.

Within the init.d script:

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="Monitor files"
NAME=monitor
DAEMON=/usr/bin/python
DAEMON_ARGS="/home/user/python/monitor.py"
PIDFILE=/home/user/logs/monitor.pid
LOGFILE=/home/user/logs/monitor.log
SCRIPTNAME=/etc/init.d/$NAME

...

do_stop()
{
    # Return
    #   0 if daemon has been stopped
    #   1 if daemon was already stopped
    #   2 if daemon could not be stopped
    #   other if a failure occurred
    start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
    RETVAL="$?"
    # Many daemons don't delete their pidfiles when they exit.
    rm -f $PIDFILE
    return "$RETVAL"
    echo "done"
}

...

case "$1" in
  start)
    [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
    do_start
    case "$?" in
            0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
            2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  stop)
    [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
    do_stop
    case "$?" in
            0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
            2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;

...

To ensure the daemon handles SIGERM properly, I can run it by hand:

bash$ /usr/bin/python /home/user/python/monitor.py
bash$ kill -Term PID

The daemon successfully handles the SIGTERM and exits properly.

I can't seem to figure out why it doesn't handle it when I do "service monitor stop" though.

R. W.
  • 357
  • 1
  • 5
  • 9
  • While it's running, does the `PIDFILE` contain the correct process ID? From your command-line example it looks like `monitor.py` turns itself into a background process, so `start-stop-daemon` might be recording the wrong PID – Simon Fraser Mar 15 '16 at 16:54
  • My previous comment assumes that `start-stop-daemon` has been told `--make-pidfile`, as otherwise it's up to `monitor.py` to write it out. (`do_start` isn't in the question) – Simon Fraser Mar 15 '16 at 16:59
  • Yes that's correct, the python program does turn itself into a background process, and the PID in the PIDFILE matches the PID of the process. And yes, it makes its own PIDFILE within the python program. – R. W. Mar 15 '16 at 17:38

1 Answers1

1

Check that the process $NAME is correct, as delivered to the start-stop-daemon --stop command. I just encountered this issue because a process I was running ended up getting a different name whenever it forked its daemon. Try running this to see the process command name:

ps -o comm= $(cat /home/user/logs/monitor.pid)

I bet yours outputs this (instead of monitor):

python

Then change your stop command to look like this, where you substitute python in place of $NAME:

start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name python
Ethan T
  • 1,390
  • 12
  • 28
  • Yep, you're 100% right. The process had been renamed to python. Your suggestion fixes it. As a follow up, could adding "python" after --name conflict with some other system process? Is there a better practice to get my daemon properly named? – R. W. Mar 26 '16 at 20:48
  • You're probably looking for something like [this](http://stackoverflow.com/questions/564695/is-there-a-way-to-change-effective-process-name-in-python). It might not be worth all that effort; if your `$PIDFILE` is properly secured (not writeable by untrusted users) then the risk should be pretty low that you'd end up killing the wrong Python-based process. As long as `$PIDFILE` lives in `/var/run` (which is usually tmpfs), it'll be zapped on a reboot, which would lessen the odds further. – Ethan T Mar 28 '16 at 17:13