CentOS 7上php-fpm无法启动的问题处理


=Start=

缘由:

现在自用的Linux主机系统我都是选的CentOS 7,用的PHP版本也升级到了PHP 7。在之前的主机、博客维护过程中已经出过不少问题,这次又碰到了一个问题——在主机因维护而重启后php-fpm没有正确启动导致博客无法正常访问,解决办法和之前的不太一样,所以在此记录一下,方便以后查阅、参考。

正文:

参考解答:
0、一些辅助命令
# ls -lt /etc/systemd/system/multi-user.target.wants/

# find / -type f -iname "php-fpm.conf" | xargs ls -lt
# grep -v '^;' /etc/opt/remi/php71/php-fpm.d/www.conf | grep 'listen'

# nginx -t
# grep "fastcgi_pass" /etc/nginx/nginx.conf
1、systemd的系统启动项

应该是从CentOS 7开始,Linux服务管理器开始用systemd来替换之前的SysVinit,很多命令和之前不太一样,具体的可以参考之前记录的一篇文章「Linux的systemd相关知识学习」,这里只提一点:

# systemd里面的.service文件一般是放在下面这个目录下,当不记得服务名称了,可以去目录里看看
# ls -lt /usr/lib/systemd/system/
# cat /usr/lib/systemd/system/php71-php-fpm.service

&

# 查看当前系统上现在有哪些开机启动项,如果不在的话使用enable进行添加
# ls -lt /etc/systemd/system/multi-user.target.wants/
# systemctl enable nginx
# systemctl enable php71-php-fpm
# systemctl enable mysqld
2、php-fpm启动失败的原因
● php71-php-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php71-php-fpm.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2018-05-05 10:38:32 CST; 36s ago
  Process: 5500 ExecStart=/opt/remi/php71/root/usr/sbin/php-fpm --nodaemonize (code=exited, status=78)
 Main PID: 5500 (code=exited, status=78)

May 05 10:38:32 ixyzero-centos systemd[1]: Starting The PHP FastCGI Process Manager...
May 05 10:38:32 ixyzero-centos php-fpm[5500]: [02-May-2018 10:38:32] ERROR: unable to bind listening socket for address '/var/run/php-fpm/php-fpm.sock': No such file or directory (2)
May 05 10:38:32 ixyzero-centos php-fpm[5500]: [02-May-2018 10:38:32] ERROR: FPM initialization failed
May 05 10:38:32 ixyzero-centos systemd[1]: php71-php-fpm.service: main process exited, code=exited, status=78/n/a
May 05 10:38:32 ixyzero-centos systemd[1]: Failed to start The PHP FastCGI Process Manager.
May 05 10:38:32 ixyzero-centos systemd[1]: Unit php71-php-fpm.service entered failed state.
May 05 10:38:32 ixyzero-centos systemd[1]: php71-php-fpm.service failed.

即,没有 `/var/run/php-fpm/php-fpm.sock` 这个文件,导致无法绑定监听端口/文件,初始化失败。

之前出现这种问题,一般是以下原因之一:

  • php-fpm的配置文件里的listen.owner/group和Nginx配置文件里的user/group不匹配,导致权限不够;
  • php-fpm的配置文件里的listen和Nginx配置文件里的fastcgi_pass不匹配,导致监听和读取的不是同一个socket文件;
3、临时解决办法

但这次不是,这次的上面2个配置都是对的,但就是 `/var/run/php-fpm/php-fpm.sock` 这个文件不存在,解决办法也很简单,就是:

# sudo mkdir -p /var/run/php-fpm/
# sudo touch /var/run/php-fpm/php-fpm.sock

# sudo systemctl start php71-php-fpm

不过,一旦机器重启,`/var/run/php-fpm/php-fpm.sock` 这个文件就又没了,而且 `/var/run/php-fpm/` 这个目录也没了,所以,这种手工创建目录、文件的方式只能临时生效。

4、长期解决办法

如果想要找到一个长期有效的办法,那就需要定位问题以及其背后的原因,否则问题还是会一直存在。

# 看 /var/run/ 目录权限
[zero@ixyzero-centos ~]$ ls -lt /var/ | grep "run"
lrwxrwxrwx.  1 root root   11 2月   3 2017 lock -> ../run/lock
lrwxrwxrwx.  1 root root    6 2月   3 2017 run -> ../run
[zero@ixyzero-centos ~]$
[zero@ixyzero-centos ~]$ ls -lt / | grep "run"
drwxr-xr-x  22 root root   620 5月   2 16:30 run

# 从上面的信息可以看出, /var/run 这个目录只有root才有「写」权限,而php-fpm的执行用户是和Nginx一样的低权限用户,所以无法创建 /var/run/php-fpm/ 子目录,从而也就无法创建 /var/run/php-fpm/php-fpm.sock 文件

# 目录 /var/run 有点「内存盘」的感觉,就是说它不是一直稳定存在的,而是只存在于内存中(网上有说法是这样会提高速度),当系统重启时,/var 下的目录便会消失,需要重新创建

综上,我将原先php-fpm的配置文件里的listen和Nginx配置文件里的fastcgi_pass都改成了 `/var/run/php-fpm.sock` ,然后将php-fpm和Nginx服务都加入系统启动项,重启系统,一切OK。

参考链接:

=END=


《“CentOS 7上php-fpm无法启动的问题处理”》 有 10 条评论

  1. 如何通过nginx、php-fpm、php的日志调试程序
    https://mp.weixin.qq.com/s/CPsjXITMHfpIWV2ylxknrA
    `
    在这四个层面(nginx、php-fpm主进程、php-fpm pool工作进程、php)都有与日志有关的指令,接下去分别描述。

    php.ini
    每一个php解析器都有一个php.ini,该文件定义了很多php的默认行为,从日志的角度看,有三个指令很重要。
    error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
    display_errors=off
    error_log=/var/log/phperror.log

    nginx.conf
    对于nginx来说,可以通过以下指令控制访问日志和错误日志,非常的简单:
    access_log logs/access.log main;
    error_log logs/error.log;

    php-fpm pool 日志
    比如:
    fpm/pool.d/www.test.com.conf
    fpm/pool.d/www.test.cn.conf

    php-fpm 日志
    暂时可以忽略
    `

  2. PHP远程代码执行漏洞预警(CVE-2019-11043)
    https://www.4hou.com/vulnerable/21160.html

    CVE-2019-11043: PHP 7 RCE漏洞分析
    https://www.4hou.com/vulnerable/21195.html
    https://thehackernews.com/2019/10/nginx-php-fpm-hacking.html
    `
    # 建议

    虽然漏洞利用只在PHP 7+版本上工作,但该漏洞本身存在于之前的版本中。很长时间内,php-fpm都不会限制脚本的扩展,比如/avatar.png/some-fake-shit.php可以将 avatar.png 作为php脚本执行。
    GitHub上的PoC脚本可以通过发送特殊伪造的请求来查询目标web服务器来识别是否受到该漏洞的影响。识别了有漏洞的目标后,攻击者可以在URL中加上’?a=’并发送伪造的请求到有漏洞的web服务器。

    因为PoC漏洞利用已经在GitHub上公布了,虽然补丁已经发布了,但是黑客可能已经利用该漏洞了。研究人员建议用户更新PHP到最新的PHP 7.3.11 或PHP 7.2.24。
    `

  3. 【漏洞通告】PHP远程代码执行漏洞(CVE-2019-11043)
    https://mp.weixin.qq.com/s/iFtnfEyL2u4skA2DY7d6yA
    `
    2.漏洞概述

    漏洞类型:远程代码执行漏洞
    危险等级:高危
    利用条件:nginx配置了fastcgi_split_path_info
    受影响系统:PHP 5.6-7.x,Nginx>=0.7.31

    3.漏洞编号
    CVE-2019-11043 PHP远程代码执行漏洞

    4.漏洞描述
    Nginx 与 php-fpm 服务器上存在远程代码执行漏洞,由于Nginx的fastcgi_split_path_info模块在处理带 %0a 的请求时,对换行符 \n 处置不当使得将 PATH_INFO 值置为空,从而导致 php-fpm 组件在处理 PATH_INFO 时存在漏洞,攻击者通过精心的构造和利用,可以导致远程代码执行。

    5.修复建议
    1).补丁包修复方案:
    目前官方尚未发布修复漏洞的补丁包,将于当地时间24日进行发布,请随时关注并进行升级。

    2).源码修复方案:
    https://bugs.php.net/patch-display.php?bug_id=78599&patch=0001-Fix-bug-78599-env_path_info-underflow-can-lead-to-RC.patch&revision=latest

    3).临时修复方案:
    Nginx 配置文件中location添加如下配置:
    try_files $uri =404
    `

    漏洞预警 | PHP 远程代码执行漏洞 (CVE-2019-11043)
    https://mp.weixin.qq.com/s/NFPVPSUHJKr4ghfa0ofoWQ

    CVE-2019-11043 PHP远程代码执行漏洞复现
    https://mp.weixin.qq.com/s/senNnIrw1cm4ND66qFWyRw
    `
    # 复现总结
    (1)利用条件苛刻,因为触发漏洞的配置不是默认配置。
    (2)即使是触发漏洞的配置,仍有失败的机率,执行命令时成功率50%的样子。
    `

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注