Question

我在nginx后面的uWSGI下运行了一个烧瓶应用程序。

*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 Unicorn上。

如果nginx进程具有对套接字的完全访问权限，那么哪里权限可能会被拒绝？

作为一个复杂因素，此服务器在其中安装了Ubuntu 14.04的容器中运行。这个设置过去常常工作......但我最近将主机升级到14.10 ......我完全明白这可能是导致问题的原因。但在我降级主机或升级容器之前，我想了解原因。

当我对生成此错误的工作人员运行strace时，我看到它正在进行的调用是这样的：

readv(14, 0x7fffb3d16a80, 1)            = -1 EACCES (Permission denied)

14似乎是此系统调用

创建的文件描述符

socket(PF_LOCAL, SOCK_STREAM, 0)        = 14

所以它无法从刚刚创建的本地套接字读取？

Answer 1

好！因此，我认为问题与this bug有关。似乎即使apparmor没有配置为阻止访问容器内的套接字，它实际上正在做一些事情来防止从它们读取（虽然不是创建......）因此关闭容器的apparmor（following these instructions）努力解决它。

两条相关的路线是：

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日志中。

Answer 2

这个问题可能是在内核3.16中引入的，因为它不会在14.04上使用3.13内核重现。奇怪的apparmor bug确实对此负责。

不幸的是@yychedee的解决方案对我不起作用。在我的情况下，我必须将以下参数添加到docker run命令以解决问题：

docker run --security-opt apparmor:unconfined ...

如果有人知道问题的当前状态，请考虑在此答案下添加评论：）

读取上游时nginx权限被拒绝 - 即使以root身份运行也是如此

2 个答案: