安装LEMP+WordPress后重启php7.2-fpm与Nginx失败求助

这种情况确实有点棘手——明明重启命令报了错，但systemctl status却显示Nginx在运行，日志也没给出明确线索。我来分享几个针对性的排查方向，你可以一步步试：

• 先做最基础的配置语法检查
  有时候Nginx在重启时会先执行配置语法校验，如果校验失败，它会尝试保留旧的运行进程（所以状态显示running），但新进程启动失败，这就会触发systemctl的报错。直接运行：

  nginx -t
  

  这个命令会直接告诉你配置文件有没有语法错误，哪怕日志里没记录。如果有错误，根据提示修改配置后再试重启。

• 拆分重启操作，单独测试Nginx启动
  你是同时重启php7.2-fpm和Nginx，可能其中一个的问题干扰了另一个的判断。先单独操作Nginx：

  systemctl stop nginx
  systemctl start nginx
  

  如果单独启动时报错，那问题就聚焦在Nginx本身；如果启动成功，那可能是两个服务重启的时序问题（比如php-fpm还没完全启动，Nginx就尝试连接它？不过这种情况日志一般会有记录）。

• 检查Nginx的实际运行进程
  有时候systemctl status的状态可能和实际进程不一致，用进程列表确认：

  ps aux | grep nginx
  

  你应该能看到至少一个主进程（root用户运行）和几个worker进程（www-data或nginx用户运行）。如果只有grep本身的进程，那说明Nginx其实没在运行，只是systemctl的状态缓存出了问题；如果进程存在，那可以进一步检查端口占用：

  ss -tulpn | grep ':80'
  ss -tulpn | grep ':443'
  

  确认这些端口确实被Nginx进程占用，没有其他程序（比如Apache、另一个Nginx实例）抢端口。

• 检查PHP-FPM的状态是否正常
  虽然你重启了php7.2-fpm，但还是要确认它真的在正常运行：

  systemctl status php7.2-fpm
  

  看输出里的Active状态是不是active (running)，有没有报错信息。如果PHP-FPM启动失败，Nginx在处理PHP请求时会出问题，但一般不会导致Nginx重启报错——不过也不排除你的Nginx配置里有依赖PHP-FPM的特殊设置（比如fastcgi_pass指向了错误的socket）。

• 临时调整Nginx日志级别到Debug
  如果常规日志没线索，可以临时把Nginx的日志级别调高，捕捉更详细的启动信息：

  1. 打开Nginx的主配置文件（一般是/etc/nginx/nginx.conf），找到error_log行，把级别改成debug：

     error_log /var/log/nginx/error.log debug;
     

  2. 保存后执行nginx -t确认配置没问题，然后重启Nginx：

     systemctl restart nginx
     

  3. 再去看/var/log/nginx/error.log，里面会有启动时的详细调试信息，大概率能找到报错的原因。调试完记得改回原来的日志级别（比如warn或error），避免日志文件过大。

• 排查SELinux的影响
  如果你的服务器开启了SELinux，它可能会在后台阻止Nginx的某些操作，但不会在常规日志里明显体现。可以临时关闭SELinux测试：

  setenforce 0
  

  然后重启Nginx，如果不再报错，那就是SELinux的权限问题，你需要添加对应的规则（比如允许Nginx访问PHP-FPM的socket，或者访问网站目录），而不是一直关闭SELinux。

• 检查Nginx服务文件的配置
  极端情况下，systemctl的服务文件可能有问题。查看Nginx的service文件（一般在/lib/systemd/system/nginx.service），看看ExecStart、ExecReload等指令是否正确，有没有自定义的重启逻辑导致冲突。如果怀疑文件有问题，可以尝试重新加载systemd配置：

  systemctl daemon-reload
  

  然后再重启Nginx。

内容的提问来源于stack exchange，提问作者Zae