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
5
  • Do you get any error messages ?
    – user9517
    Jun 5, 2012 at 6:32
  • @Iain: None that I can find, though I'm very unfamiliar with Linux servers so I might just not know where to look. Jun 5, 2012 at 6:34
  • 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.
    – user9517
    Jun 5, 2012 at 6:38
  • @Iain: I added 1>> /tmp/rhode1.log 2>> /tmp/rhode2.log to both lines with --exec; the files get created but remain empty. Jun 5, 2012 at 6:46
  • 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. Jun 5, 2012 at 13:47

4 Answers 4

1

Have you tried the supplied init.d script?

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

1
  • That line runs paster, which is what my script does. Jun 5, 2012 at 6:01
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.

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.

4
  • 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. Jun 5, 2012 at 5: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? Jun 5, 2012 at 5: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 5, 2012 at 6: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). Jun 5, 2012 at 6: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.

1
  • 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? Jun 5, 2012 at 6:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .