主页 / server / 问题 / 977936
Accepted
Machavity
Asked: 2019-08-05 15:33:26 +0800 CST

PHP-FPM + nginx 产生权限被拒绝，但仅在某些大页面上

  • 772

我有一个 AWS Lightsail 实例（1GB RAM 实例）运行一个相对较新的网站（即几乎没有流量）。它正在运行 nginx 和 PHP-FPM 7.3（也尝试使用 7.2）和 MariaDB。所有这些都在 CentOS 7 下。

在 AWS 免费套餐下一切正常。我运行了一个 T2.micro EC2 实例和一个 T2.micro RDS 实例。Lightsail 有点……更敏感。为了使 Lightsail 正常工作，我将 PHP-FPM 切换到ondemand

按需 - 启动时不创建子级。当新请求连接时，孩子将被分叉。

我必须这样做，否则 MariaDB 会随机崩溃。这似乎不会影响下面的问题。

Wordpress 管理面板停止正常工作，每个人都说要CONCATENATE_SCRIPTS关闭。那行得通……主要是。帖子和模板的编辑器都出现故障。没有人能够给我一个线索为什么。环顾四周，我自己发现了一些东西。

不工作的页面没有完全加载。CONCATENATE_SCRIPTS启用后，CSS 文件将加载到一个巨大的页面中。因为这无法完全渲染，所以浏览器会忽略 CSS 和 JS 文件。CONCATENATE_SCRIPTS通过简单地将它们拆分为更小且易于加载的组件文件来解决此问题。但是编辑页面不能拆分，调试底层问题一直很抓狂。我收到 200 响应和一些数据

页面返回 200

但是页面绘制不完整。我会说可能有 80-90% 的 HTML 在那里，但被切断了。在从这里开始的部分（JS 块）

wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( {"\/":{"body":{"name":"S

它只是突然结束，并且每次都在同一点。就好像 PHP-FPM 或 nginx 刚刚停止，但没有任何错误日志（关于这种设置的大多数其他问题都是针对根本不绘制的页面）。更奇怪的是，它不是针对较小的页面，而是针对非常长的页面。没有窃取时间，top实例似乎没有承受任何严重的负载，所以我不确定它为什么会这样做。我重新加载了所有文件，甚至建立了一个单独的 WP 站点来测试它，他们都这样做了。

根据评论，我打开了 nginx 调试日志记录并发现

2019/08/07 02:33:08 [crit] 1461#0: *47 open() "/var/lib/nginx/tmp/fastcgi/3/00/0000000003" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: example.com, request: "GET /wp-admin/post-new.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000",

这没有任何意义，为什么它会只对少数大文件执行此操作。没有驱动器已满或靠近它。我读了这个问题，但 nginx 和 PHP-FPM 都在apache. 删除 tmp 文件也没有解决它。这些目录归 拥有apache:root，但将它们更改为apache:apache无效。SELinux 似乎也不是罪魁祸首。我也不用proxy_cache。

nginx

1 个回答

  1. Best Answer

    首先，失败与FastCGI 缓冲有关，而不是代理缓存。

    这从/var/lib/nginx/tmp/fastcgi....

    为什么您只在特别大的页面上遇到错误：如果您配置的 FastCGI 缓冲区不足以将 PHP-FPM 的整个响应放入内存中，当然这种情况在大响应时会更频繁地发生，NGINX 将尝试写入部分对临时文件的响应。

    显然，保存 FastCGI 临时文件的目录的权限不允许 NGINX 将文件保存在其中，因此当响应“太大”时，它会在某个点完全失败。

    该路径/var/lib/nginx/tmp/fastcgi还表明您没有使用官方的 NGINX 发行版，因为如果您使用了，那么您最终将/var/cache/nginx/fastcgi_temp拥有nginx:root.

    我建议使用股票，官方 NGINX 发行版。

    但是 nginx 和 PHP-FPM 都在 apache 下运行

    题外话，但是：无论如何，这都是不正确的设置。正确的设置是以一个用户身份运行 NGINX（无论apache是. 然后让您的用户成为组的成员。没有理由仅仅因为您在给定服务器上只有一个应用程序而在单个用户下运行所有​​内容。nginxfoonginxfoo

    无论哪种方式，将其视为一个典型chmod问题：

    • 检查运行的用户 NGINX 工作进程（user配置中的指令）
    • 尝试使用该用户从上到下列出相关目录的文件，直到找到它停止工作的位置，然后递归地修复权限。

    例如，假设您的 NGINX 工作进程确实像您所说的那样由apache用户运行并且它无法访问/var/lib/nginx/tmp/fastcgi：

    sudo -u apache ls /var/

    这行得通吗？权限很好，可以通过NGINX工作进程的用户遍历到这个目录。重要的是要了解您需要能够遍历（如rx许可）所有上层目录，以便能够读取下面任何目录的内容。也就是说，对于我们的“最终目的地”，也就是/var/lib/nginx/tmp/fastcgi，我们需要能够阅读所有的/var,/var/lib等。

    如果阅读/var不起作用（尽管会表明某种损坏的系统），您需要让“其他人”阅读它，例如chmod o+rX /var

    sudo -u apache ls /var/lib

    这行得通吗？/var/lib 的权限很好。如果没有，您需要让其他人阅读它：chmod o+rX /var/lib

    sudo -u apache ls /var/lib/nginx

    这行得通吗？如果没有，请通过 . 检查所有权和权限stat。然后确保 NGINX 用户是目录的所有者，/var/lib/nginx并且chmod（这次是“所有者”）允许它遍历目录：

    chown apache:root /var/lib/nginx
chmod u+rX /var/lib/nginx

    确保相同（由 NGINX 的用户拥有，可以被它读取（遍历））/var/lib/nginx/tmp

    最后，/var/lib/nginx/tmp/fastcgi您需要 NGINX 用户能够执行所有读取、执行（遍历）和写入操作：

    chown apache:root /var/lib/nginx/tmp/fastcgi 
chmod 0700 /var/lib/nginx/tmp/fastcgi

    所以基本上它是一个冲洗，重复操作，同时遍历相关文件，直到它工作。

    通过尝试列出目录的内容并在其中创建文件来验证所有设置是否正确：

    sudo -u apache ls /var/lib/nginx/tmp/fastcgi
sudo -u apache touch /var/lib/nginx/tmp/fastcgi/test.txt
    • 6

相关问题