在似乎是一个随机发生的情况下，一个网站在今晚晚上去了，看了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. 现在我读了mod_wsgi的ConfigurationIssues wiki，修复看起来很合理。 无法写入该目录，因此必须使用WSGISocketPrefix指定替代scheme
所以我设定了：
WSGISocketPrefix /var/run/wsgi
它解决了这个问题，并且该站点可以在Apache重启之后加载。
但是，我很好奇 – 为什么这个dirctory停止写入？ 我错过了什么吗？ /var/run/apache2目录由root:root拥有，但现在在/var/run/wsgi*.sock下运行的新套接字是www-data:root 。有一个服务器重新启动，但就是这样。 也许有什么东西现在接pipe对该目录启动权限？
有任何想法吗？ 谢谢！
如果您已经完成了Apache的平稳重启，并且Apache工作进程仍然有活动的套接字连接尚未调用到mod_wsgi守护程序进程的初始请求或后续请求（由于保持活动状态）在sockets上。
这将发生，因为在平稳的重新启动mod_wsgi守护进程重新启动，无论如何这样做，套接字文件的path是变化如此不同。 这意味着旧的工作进程挂起来处理当前的和保持活动的请求将无法连接到守护进程，因为他们仍然会尝试使用旧的套接字文件path。
至于套接字文件的目录，重要的是这个目录对www数据是可读的。 套接字最初将以root身份创build，使用perm 0600，然后将所有权更改为www-data，以便www-data工作进程可以连接，而不是其他任何东西。 这依赖于www数据仍然可以访问的目录。
WSGISocketPrefix的原因是Redhat在Apacheconfiguration中把日志目录设置为默认的日志目录，使其他人无法读取，因此www-data无法在目录中看到套接字。 这就是为什么Redhat需要将其更改为/ var / run。
在什么时候目录权限被修改或修正，以及是否可以在没有Apache包升级的情况下发生，不知道。