我有一个应用程序在uWSGI后面运行nginx。
*1 readv() failed (13: Permission denied) while reading upstream, client: 10.0.3.1, server: , request: "GET /some/path/constants.js HTTP/1.1", upstream: "uwsgi://unix:/var/uwsgi.sock:", host: "dev.myhost.com" 在套接字上的权限是可以的（666，并设置为与nginx相同的用户），事实上，即使当我以root身份运行nginx我仍然得到这个错误。
烧瓶app / uwsgi正在发送请求。 但是Nginx并没有读取它。 这是Ubuntu Utopic独angular兽。
任何想法，如果nginx进程可以完全访问套接字，权限可能会被拒绝？
作为一个复杂的因素，这台服务器运行在一个安装了Ubuntu 14.04的容器中。 而这个设置曾经工作…但我最近升级到14.10主机…我可以完全明白，这可能是问题的原因。 但在降级主机或升级容器之前，我想了解原因。
当我在一个产生这个错误的工作者上运行strace时，我看到它所做的调用是这样的：
readv(14, 0x7fffb3d16a80, 1) = -1 EACCES (Permission denied)
14似乎是由这个系统调用创build的文件描述符
socket(PF_LOCAL, SOCK_STREAM, 0) = 14
所以它不能从它刚刚创build的本地套接字读取？
好的！ 所以我认为，这个问题与这个bug有关 。 看来，即使apparmor没有配置为阻止访问容器内的套接字，实际上是在做一些事情来阻止对它们的读取（尽管不是创建的），所以关闭容器的apparmor（ 按照这些指示 ）工作修理它。
有关的两条线是：
sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start
sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/
并添加
lxc.aa_profile = unconfined
到容器配置文件。
注意：这些错误没有记录在任何apparmor日志中。
这个问题可能是在内核3.16中引入的，因为它不能在14.04上用3.13内核重现。 奇怪的apparmor错误确实是负责。
不幸的是，@ aychedee的解决方案并不适合我。 在我的情况下，我不得不将以下参数添加到docker run命令来摆脱该问题：
docker run --security-opt apparmor:unconfined ...
如果有人意识到问题的当前状态，请考虑在此答案下添加评论:)