uWSGI Server log…permission denied to read file...which file?
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
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.
你可以尝试strace
这个过程,看看是什么原因引发的错误消息,是这样的:
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