uWSGI Server log…permission denied to read file...which file?

Question

I have a server running Django/Nginx/uWSGI with uWSGI in emperor mode, and the error log for it (the vassal-level error log, not the emperor-level log) has a continual permissions error every time it spawns a new worker, like so:

Tue Jun 26 19:34:55 2012 - Respawned uWSGI worker 2 (new pid: 9334)

Error opening file for reading: Permission denied

Problem is, I don't know what file it's having trouble opening; it's not the log file, obviously, since I'm looking at it and it's writing to that without issue. Any way to find out? I'm running the apt-get version of uWSGI 1.0.3-debian through Upstart on Ubuntu 12.04. The site is working successfully, aside from what seems like a memory leak...hence my looking at the log file. I've experimented with changing the permissions of the entire /opt/ directory to include the uwsgiuser user, to no avail. I'm using a TCP socket, so permissions shouldn't be an issue there. Is it the cache? Does that have its' own permissions? If so, where?

My Upstart conf file

description "uWSGI" start on runlevel [2345] stop on runlevel [06] respawn

env UWSGI=/usr/bin/uwsgi env LOGTO=/var/log/uwsgi/emperor.log

exec $UWSGI \
--master \
--emperor /etc/uwsgi/vassals \
--die-on-term \
--auto-procname \
--no-orphans \
--logto $LOGTO \
--logdate

My Vassal ini file:

[uwsgi]
# Variables
base = /opt/env/mysiteenv

# Generic Config
uid = uwsgiuser
gid = uwsgiuser
socket = 127.0.0.1:5050
master = true
processes = 2
reload-on-as = 128
harakiri = 60
harakiri-verbose = true
auto-procname = true
plugins = http,python
cache = 2000
home = %(base)
pythonpath = %(base)/mysite
module = wsgi
logto = /opt/log/mysite/error.log
logdate = true

Answer 1

The actual answer to this question appears to be this Ubuntu-specific bug:

https://bugs.launchpad.net/ubuntu/+source/libjpeg-turbo/+bug/1031718

You can work around the problem by putting the lines

setuid uwsgiuser
setgid uwsgiuser

into your upstart configuration file, and deleting the uid and gid settings from your uwsgi configuration.

Answer 2

You could try to strace the process and see what triggers the error message, something like:

UWSGI=/usr/bin/uwsgi LOGTO=/var/log/uwsgi/emperor.log strace -f -o strace.log -etrace=open,write $UWSGI --master --emperor /etc/uwsgi/vassals --die-on-term --auto-procname --no-orphans --logto $LOGTO --logdate