2

I am trying to set up a django project on my VPS. I am trying to get a uWSGI Emperor to run and thus spawn vassals. I have set up all my config files as suggested by numerous websites including the uWSGI documentation. Yet when I run the file command

paul@example:/$ sudo service uwsgi start
I get the following:

start: Unknown job: uwsgi

I figured this was because Upstart couldn't recognize the uwsgi.conf file http://uwsgi-docs.readthedocs.org/en/latest/Upstart.html I have in /etc/init/. But after review I can not find anything wrong with it.

paul@example:/etc/init$ sudo vim uwsgi.conf
# Emperor uWSGI script

pre-start script
    logger "pre-start for uWSGI Emperor"
end script

post-start script
    logger "post-start for uWSGI Emperor"
end script

description "uWSGI Emperor"

start on runlevel [2345]
stop on runlevel [!2345]

respawn

env LOGTO = /var/log/uwsgi.log

exec /usr/local/bin/uwsgi --master --die-on-term --emperor /etc/uwsgi/vassals --logto $LOGTO

I also checked over my /etc/uwsgi/vassals files to make sure they were in working order. My only file right now is a mysite.ini file:

paul@example:/etc/uwsgi/vassals$ sudo vim mysite.ini 
[uwsgi]
base = /home/paul/djprojs/mysite/
chdir = %(base)
master = true
threads = 20
socket = /tmp/sockets/%n.sock
home = /home/paul/.virtualenvs/dj
env = DJANGO_SETTINGS_MODULE=%n.settings
module = django.core.handlers.wsgi:WSGIHandler()

But this looks okay to me also.

Finally, to test and see if uWSGI would run from the command line, I started it without Upstart. I ran

paul@exmaple/$ uwsgi --emperor /etc/uwsgi/vassals

and it worked:

*** Starting uWSGI 1.9.13 (32bit) on [Sat Jul 27 19:23:43 2013] ***
compiled with version: 4.6.3 on 21 July 2013 03:35:50
os: Linux-3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 12:51:49 UTC 2012
nodename: example.me
machine: i686
clock source: unix
detected number of CPU cores: 1
current working directory: /
detected binary path: /usr/local/bin/uwsgi
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 3922
your memory page size is 4096 bytes
detected max file descriptor number: 1024
*** starting uWSGI Emperor ***
*** has_emperor mode detected (fd: 6) ***
[uWSGI] getting INI configuration from mysite.ini
*** Starting uWSGI 1.9.13 (32bit) on [Sat Jul 27 19:23:43 2013] ***
compiled with version: 4.6.3 on 21 July 2013 03:35:50
os: Linux-3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 12:51:49 UTC 2012
nodename: example.me
machine: i686
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/local/bin/uwsgi
your processes number limit is 3922
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address /tmp/sockets/mysite.sock fd 3
Python version: 2.7.3 (default, Apr 10 2013, 06:03:17)  [GCC 4.6.3]
Set PythonHome to /home/paul/.virtualenvs/dj
Python main interpreter initialized at 0x9bdb000
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 410112 bytes (400 KB) for 20 cores
*** Operational MODE: threaded ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x9bdb000 pid: 18213 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 18213)
spawned uWSGI worker 1 (pid: 18214, cores: 20)

Then I was left without a bash prompt. The uWSGI cli shows all the server requests and doesn't return to let me type another command. I really feel like there must be a better way to do this (aka. using 'sudo service uwsgi start/restart') but I'm not sure how. I have looked into this post but I'm not sure a different runlevel would solve the issue at hand.

3
  • 2
    Does sudo initctl reload-configuration cause the upstart job to be recognized? Jul 28, 2013 at 0:37
  • Hi @MarkWagner. Yes sudo initctl reload-configuration gives the same results. After tinkering with it, I'm almost sure its an issue with the uwsgi.conf file. Just not sure what about it is incorrect.
    – Paul
    Jul 28, 2013 at 23:59
  • This is tangental but you may want to drop --master from your exec line to prevent this issue: stackoverflow.com/questions/15055002/… Aug 23, 2013 at 15:09

3 Answers 3

4

Figure it out. Not sure I know how though. I think it was the LOGTO portion of the uwsgi.conf file that made it not work. This is my uwsgi emperor file now:

description "uWSGI Emperor"

start on runlevel [2345]
stop on runlevel [!2345]

respawn

exec uwsgi --emperor /etc/uwsgi/vassals/ --master --uid www-data --gid www-data --logto /var/log/uwsgi/emperor.log

And this is my vassal, ie. mysite.ini

[uwsgi]
base = /home/paul/djprojs/mysite
chdir = %(base)
module = mysite.wsgi:application
pidfile = /tmp/uwsgi_vassal_%n.pid
socket = /tmp/sockets/%n.sock
vacuum = True
wsgi-file = /home/paul/djprojs/mysite/mysite/wsgi.py
home = /home/paul/.virtualenvs/dj

Still working on how to clean it up but it is working like a beaut.

3

The job is invalid - just run 'init-checkconf job.conf' and it will tell you what the problem is:

ERROR: File /tmp/job.conf: syntax invalid:
init:aa.conf:18: Unexpected token

In summary, you can't have spaces between the key and value in an env stanza. See init(5) for stanza syntax.

0
0

While an old question, I suspect I've just spent the last several hours bashing my head into a wall for the same issue. For me, uWSGI was trying to work with a file in a folder it did not have permissions in. A simple chmod on the directory in question fixed it all (the log files for me). The issue was constantly appearing to be something else, but in the end that's all it took. Might not be the true answer to your problem, but hopefully it might help someone else out there suffering as I have been.

You must log in to answer this question.

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