1

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
Stephen Jennings
  • 1,383
  • 3
  • 23
  • 30

4 Answers4

1

Have you tried the supplied init.d script?

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

patrician
  • 23
  • 1
  • 4
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.

Stephen Jennings
  • 1,383
  • 3
  • 23
  • 30
0

I believe what you're missing is something to load the virtualenv environment. I've run into the same sort of problems with Ruby's RVM which is similar to virtualenv. Accord to the docs you'll need to use activate in your script.

kashani
  • 3,922
  • 18
  • 18
  • How specifically would I achieve that? I tried [this method](http://blag.felixhummel.de/admin/venv_initd.html) but I couldn't get this to work; the processes didn't seem to want to run as `rhodeuser`. – Stephen Jennings Jun 05 '12 at 05:54
  • 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 Jun 05 '12 at 05:55
  • 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. – kashani Jun 05 '12 at 06:08
  • 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). – Stephen Jennings Jun 05 '12 at 06:10
0

You need to add source $VENV_DIR/bin/activate to your script before executing the commands. When you are running it as your own user you have likely already activated the virtual environment.

Kamil Kisiel
  • 11,946
  • 7
  • 46
  • 68
  • 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? – Stephen Jennings Jun 05 '12 at 06:04