![Apache,mod_wsgi 上的权限被拒绝,使用 WSGISocketPrefix 修复——但是为什么呢?](https://linux22.com/image/569423/Apache%EF%BC%8Cmod_wsgi%20%E4%B8%8A%E7%9A%84%E6%9D%83%E9%99%90%E8%A2%AB%E6%8B%92%E7%BB%9D%EF%BC%8C%E4%BD%BF%E7%94%A8%20WSGISocketPrefix%20%E4%BF%AE%E5%A4%8D%E2%80%94%E2%80%94%E4%BD%86%E6%98%AF%E4%B8%BA%E4%BB%80%E4%B9%88%E5%91%A2%EF%BC%9F.png)
一个网站今晚瘫痪了,这似乎是一次随机事件,查看了 Apache 错误日志后,发现了这个问题:
(13)Permission denied: mod_wsgi (pid=2751): Unable to connect to WSGI daemon process 'mysite.com-ssl' on '/var/run/apache2/wsgi.2579.0.2.sock' after multiple attempts.
现在我读到配置问题wiki 中的 mod_wsgi,修复似乎合理。无法写入该目录,因此必须使用以下方法指定替代方案:WSGISocketPrefix
所以我设置:
WSGISocketPrefix /var/run/wsgi
它修复了该问题,并且网站可以在 Apache 重启后加载。
但是,我很好奇 - 为什么这个目录不再可写?我是不是漏掉了什么?该/var/run/apache2
目录归 拥有root:root
,但现在在其下运行的新套接字/var/run/wsgi*.sock
是www-data:root
.. 服务器重新启动了,但仅此而已。也许现在有什么东西在启动时接管了该目录的权限?
有什么想法吗?谢谢!
答案1
如果您已完成 Apache 平稳重启,并且 Apache 工作进程的套接字连接仍处于活动状态,但尚未调用 mod_wsgi 守护进程来处理初始请求或由于套接字保持活动而产生的后续请求,那么您看到的错误也可能作为暂时性问题发生。
发生这种情况的原因是,在正常重启时,mod_wsgi 守护进程无论如何都会重新启动,并且在执行此操作时,套接字文件的路径会发生很大变化。这意味着挂起以处理当前和保持活动请求的旧工作进程将无法连接到守护进程,因为它们仍将尝试使用套接字文件的旧路径。
至于套接字文件所在的目录,重要的是 www-data 可以读取该目录。套接字将以 root 身份创建,权限为 0600,然后所有权应更改为 www-data,以便 www-data 工作进程可以连接,而不能进行其他操作。这取决于 www-data 仍可访问该目录。
WSGISocketPrefix 的原因是 Redhat 将 Apache 配置中要放置这些内容的日志目录设为默认目录,但其他人无法读取,因此 www-data 无法看到目录中的套接字。这就是为什么在 Redhat 上需要将其更改为 /var/run。
不知道在什么时候目录权限会发生改变或修复,以及是否可以在不升级 Apache 包的情况下发生这种情况。