☰

设置：

tag-icon • tag-icon nginx php-fpm vagrant
设置：

设置：

我有一个虚拟盒（vagrant），里面运行着 nginx + php-fpm。我加载了 xdebug 模块。版本：

操作系统：

uname -a
Linux vagrant-ubuntu-vivid-64 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11 14:16:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

php5-fpm：

php5-fpm -v
PHP 5.6.4-4ubuntu6.2 (fpm-fcgi) (built: Jul  2 2015 15:59:03)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.2.6, Copyright (c) 2002-2014, by Derick Rethans

nginx的：

nginx -V
nginx version: nginx/1.6.2 (Ubuntu)
TLS SNI support enabled

问题：

由于未知原因，我得到了：

upstream timed out (110: Connection timed out) while 
reading response header from upstream

我尝试了 php5-fpm 的 unix 套接字设置和 TCP 设置 - 都因相同的错误而失败。

使用套接字设置，我尝试将监听权限更改为读写，甚至更改为777- 没有区别。为了以防万一，www.conf套接字的配置（）示例：

listen.owner = www-data
listen.group = www-data
listen.mode = 0666

并且用户存在：

id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)

使用 TCP 设置但是，我有：

$ telnet 127.0.0.1 9000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

这意味着它确实在监听该端口。另外，还要进行另一项检查：

netstat -tulpn | grep 9000
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      4396/php-fpm.conf)

我也尝试禁用 xdebug - 只是为了确保到达那里的连接没有问题（但事实上，这是毫无意义的，因为我的 IDE 是在主机上启动的，因此它的端口与 VM 内的端口无关）。

我尝试将其设置fastcgi_read_timeout为max_execution_time非常高的值（数千秒），但这也无济于事。

那么什么可能导致此行为以及如何解决此案？或者至少，我可以做些什么来调试此案？

更新：

当我设置非常高的超时时间时，服务器会做出响应。但事实是 - 我发现这不是应用程序问题，因为：

  • 应用程序基本上只是在日志文件中写入消息
  • 该请求因未知原因“挂起”几分钟，并且后该请求会与应用程序日志一起出现在 nginx 访问日志中（因此，当请求出现在 nginx 日志中时，应用程序会立即记录请求）

有了以上内容，我现在很困惑：nginx 告诉我们网关超时。这应该意味着：请求到达 nginx，然后在 nginx 和它的后端（因此，在本例中为 php5-fpm）之间超时。如果请求在出现在 nginx 日志之前就“挂起”了 - 后端怎么会负责？我的意思是，为什么 nginx 会出现“上游超时”？

因此，问题是——什么原因导致了这种延误？

如果需要任何其他信息-我会提供。

我也在 SO/SF 上尝试过类似的问题，但没有帮助

答案1

问题已解决。问题出在 vagrant 设置中：

# Shared folder
config.vm.synced_folder "./../", "/vagrant/",
        :nfs => true

由于应用程序试图将日志写入共享文件夹，因此它被卡住了，因为记录器的实现试图通过以下方式在文件上应用锁定flock()在 NFS 的情况下它根本无法正常工作。

因此，解决方案是：

  • 要么将共享文件夹挂载为 NFS 设备
  • 或者不使用文件锁。虽然此选项似乎是解决问题的“更简单”方法 - 但它也有缺点，因为如果您的应用程序使用供应商预定义的包（例如通过 composer），则很难意识到应用程序是否正在使用可能像本例一样失败的东西。

相关内容