(guest@joequery.me)~ $ |

Resolving UWSGI symbolic link issues

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)

raw source

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)

raw source

Date published - December 31, 2012