Init.d script works when run manually, but not on reboot

Question

I'm trying to setup a RhodeCode server on Ubuntu 12.04. I have everything installed into a virtualenv, and everything works properly when I run it from the console (paster serve production.ini).

I wrote an init.d script to start it on boot, but it does not seem to work. When I execute sudo /etc/init.d/rhodecode start manually, I see "Starting RhodeCode" echoed to the console and everything works. However, if I reboot, or if I use sudo service rhodecode start, I do see the message echoed to the console, but the Python processes are not running.

I've installed the script using update-rc.d rhodecode defaults.

From researching how to achieve this, the sources I've found have suggested I don't need to run source /usr/rhode/venv if I run the python directly from the virtualenv directory. Successfully running this from the console without activating any virtualenv first seems to support this theory. The virtualenv page seems to confirm this:

If you directly run a script or the python interpreter from the virtualenv's bin/ directory (e.g. path/to/env/bin/pip or /path/to/env/bin/python script.py) there's no need for activation.

For more details on how I've set the server up, this Gist shows my notes on what I've done so far: Installing RhodeCode 1.3.6 on Ubuntu Server 12.04

/etc/init.d/rhodecode

#!/bin/sh

### BEGIN INIT INFO
# Provides:       rhodecode
# Required-Start: $all
# Required-Stop:  $all
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Short-Description: Starts RhodeCode
### END INIT INFO

USER=rhodeuser

VENV_DIR=/usr/rhode/venv
DATA_DIR=/usr/rhode/data

CELERY_ARGS="$VENV_DIR/bin/paster celeryd $DATA_DIR/production.ini"
RHODECODE_ARGS="$VENV_DIR/bin/paster serve $DATA_DIR/production.ini"

CELERY_PID_FILE=/var/run/celeryd.pid
RHODECODE_PID_FILE=/var/run/rhodecode.pid

start_celery() {
    /sbin/start-stop-daemon \
        --start \
        --background \
        --chuid $USER \
        --pidfile $CELERY_PID_FILE \
        --exec $VENV_DIR/bin/python -- $CELERY_ARGS
}

start_rhodecode() {
    /sbin/start-stop-daemon \
        --start \
        --background \
        --chuid $USER \
        --pidfile $RHODECODE_PID_FILE \
        --exec $VENV_DIR/bin/python -- $RHODECODE_ARGS
}

stop() {
    /sbin/start-stop-daemon \
        --stop \
        --user $USER
}

case "$1" in
    start)
        echo "Starting Celery"
        start_celery
        echo "Starting RhodeCode"
        start_rhodecode
        ;;
    stop)
        echo "Stopping RhodeCode and Celery"
        stop
        ;;
    restart)
        echo "Stopping RhodeCode and Celery"
        stop
        echo "Starting Celery"
        start_celery
        echo "Starting RhodeCode"
        start_rhodecode
        ;;
    *)
        exit 2
        ;;
esac

exit 0

Solution 1

I hate this sort of "answer", but it seems I must have somehow damaged that installation without realizing it. I removed the entire RhodeCode virtualenv and re-created it according to my notes, and now the init.d script works properly when I call it via service rhodecode start.

I wish I knew what I had done wrong the first time.

Solution 2

Have you tried the supplied init.d script?

I think --exec $DAEMON -- $DAEMON_OPTS part is missing in your script.

Comments

[user9517]

Do you get any error messages ?

[Stephen Jennings]

@Iain: None that I can find, though I'm very unfamiliar with Linux servers so I might just not know where to look.

[user9517]

look in /var/log for logs. If there is nothing relevant there then try redirecting stdout/stderr from the commands in your script to a known file.

[Stephen Jennings]

@Iain: I added 1>> /tmp/rhode1.log 2>> /tmp/rhode2.log to both lines with --exec; the files get created but remain empty.

[Stephen Jennings]

Whoever is downvoting, let me know what more information I should add. I've added everything I know to be relevant, but I'll add any information you need.

[Stephen Jennings]

How specifically would I achieve that? I tried this method but I couldn't get this to work; the processes didn't seem to want to run as rhodeuser.

[Stephen Jennings]

Also, if I had to activate the virtualenv first, then why would it work from the console (no virtualenv activated) but not the service command?

[Stephen Jennings]

I have not activated the virtualenv when I run it from the console. What would be different so that I needed to activate it when I run from service but not from the console?

[kashani]

I had assumed that your current shell was autoloading virtualenv. I don't see how it could work if you weren't loading virtualenv because otherwise the programs you're trying to run would not be in your path.

[Stephen Jennings]

My understanding is that "activating a virtualenv" is just a shortcut for typing "/path/to/venv/bin/python" all the time. The virtualenv website seems to confirm this belief that running the python interpreter in the venv is the same thing (I've edited my question with the quote).