A typical UWSGI ini file may look something like
1 2 3 4 5 6 7 8 9 10 11 12 | [uwsgi] project = myapp chdir = /var/www/myapp.com daemonize = /var/log/nginx/access.log master = true socket = 127.0.0.1:5000 wsgi = %(project):app virtualenv = env/ pidfile = /var/run/uwsgi/%(project).pid touch-reload = /var/run/uwsgi/%(project).pid processes = 3 procname-prefix = %(project) |
chdir
is convenient because it lets us specify the project
, virtualenv
,
and similar options in terms of the directory we assign to chdir
. For
example, project
is treated as /var/www/myapp.com/myapp
.
So what exactly does chdir
do internally, and how can it cause problems with
symbolic links?
chdir()
If you read through the UWSGI C source, you'll discover it calls the
chdir() function when the chdir
option is provided. If you read through
the function documentation, you'll see
... If the last component of path is a symbolic link, chdir() resolves the contents of the symbolic link
So if you pass a symbolic link to chdir
, the directory path the link
references is what will be used in the "substitutions" of project
and
virtualenv
. Once you run uwsgi with this symlink, you'll notice errors
related to virtualenv occuring. This is because the paths don't exactly match
up, even though they essentially point to the same place.
The solution
A quick fix is to just create a variable that holds the projects directory, and then use this variable within the other variables.
1 2 3 4 5 6 7 8 9 10 11 12 | [uwsgi] mydir = /var/www/myapp.com project = %(mydir)/myapp daemonize = /var/log/nginx/access.log master = true socket = 127.0.0.1:5000 wsgi = %(mydir)/%(project):app virtualenv = %(mydir)/env/ pidfile = /var/run/uwsgi/%(project).pid touch-reload = /var/run/uwsgi/%(project).pid processes = 3 procname-prefix = %(project) |