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

匿名 (未验证) 提交于 2019-12-03 01:31:01

问题:

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 

回答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.



回答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



标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!