CODEWITHSUNDEEP
djangolinuxubuntuvirtualenvupstart
Mridang Agarwalla
Mridang Agarwalla

Reputation: 45098

Getting Django in a VirtualEnv to run through Upstart

I've been trying to trudge through the docs and examples to get my Django running through upstart so I can have it running all the time but am unable to so.

Here's my upstart configuration file located at /etc/init/myapp.conf:

start on startup
#expect daemon
#respawn
console output

script
  chdir /app/env/bin
  exec source activate
  exec /app/env/bin/python /app/src/manage.py runserver 0.0.0.0:8000 > /dev/null 2>&1 &
end script

When I type sudo service myapp start, the console says that it has started but it doesn't seem to be running.

Is it possible to see some debugging output to see what's going wrong? I need to run my Django application as another user — i.e. djangouser. How can I do so?

(I've been commenting out some lines to test where the service is going wrong). This is not for production use but my internal development use only.

Thanks.

Edit #1:

I have wrapped both my commands into a simple script at /app/run.sh

#!/bin/bash

cd /app/env/bin
source activate
cd /app/src
python manage.py runserver 0.0.0.0:8000 > /dev/null 2>&1 &

..and I've modified my /etc/init/myapp.conf to 

start on startup
expect daemon

exec su - djangouser -c "bash /app/run.sh"

When executing sudo service myapp start — the application starts but the PID is wrong and I can't seem to kill it with sudo service myapp stop

Any ideas?

Upvotes: 2

Views: 5241

Answers (4)

Michael Rice
Michael Rice

Reputation: 8204

This should work on Ubuntu 14.04 and possibly other versions as well:

root@vagrant-ubuntu-trusty-64:/etc/init# service my_app start 
my_app start/running, process 7799

root@vagrant-ubuntu-trusty-64:/etc/init# cat /var/log/upstart/my_app.log 

Performing system checks...

System check identified no issues (0 silenced).

You have unapplied migrations; your app may not work properly until they are applied.
Run 'python manage.py migrate' to apply them.

June 30, 2015 - 06:54:18
Django version 1.8.2, using settings 'my_test.settings'
Starting development server at http://0.0.0.0:8080/
Quit the server with CONTROL-C.

root@vagrant-ubuntu-trusty-64:/etc/init# service my_app status
my_app start/running, process 7799
root@vagrant-ubuntu-trusty-64:/etc/init# service my_app stop
my_app stop/waiting
root@vagrant-ubuntu-trusty-64:/etc/init# service my_app status
my_app stop/waiting

Here is the config to make it work:

root@vagrant-ubuntu-trusty-64:/etc/init# cat my_app.conf 

description "my_app upstart script"

start on runlevel [23]

respawn

script
    su vagrant -c "source /home/vagrant/dj_app/bin/activate; /home/vagrant/dj_app/bin/python /home/vagrant/my_test/manage.py runserver 0.0.0.0:8080"
end script

Upvotes: 0

Meehow
Meehow

Reputation: 1061

su is problematic becouse it forks the process. You can use sudo -u djangouser instead or simply add

setuid djangouser

in your conf file.

Upvotes: 0

Muhia NJoroge
Muhia NJoroge

Reputation: 551

How about using nginx and uwsgi with your virtualenv. this will give you a production like environment but will also start your django app at start up. if you are using ubuntu 10 you should take a look at uwsgi-python, otherwise just install the latest uwsgi. i usually start my virtualenv in uwsgi like so : 

sudo nano /etc/uwsgi-python/apps-available/app.xml

<uwsgi>
   <socket>127.0.0.1:8889</socket>
  <pythonpath>/home/user/code/</pythonpath>
  <virtualenv>/home/user/code</virtualenv>
  <pythonpath>/home/user/code/app</pythonpath>
   <app mountpoint="/">
    <script>uwsgiApp</script>
  </app>
</uwsgi>

also setup yournginx files at /etc/nginx/apps-available/default (the file is a bit straight forward). this will help you have your django app at all times,

Upvotes: 1

jpic
jpic

Reputation: 33420

Change:

exec source activate

By just:

source activate

This will load the virtual environment. You should probably drop the other "exec". If that doesn't work, please post your upstart logs.

A couple of remarks:

  • logging the output to somewhere else than /dev/null might be useful :)
  • runserver is not ment to be stable, I see it crashing sometimes and in that case i guess you'll need to force upstart to reload, or put the runserver call in a while loop
  • you will not be able to use an interactive debugger like ipdb with this setup

Upvotes: 1

Related Questions