PHP -fpm 服务启动失败，但是手动启动可以？

[azev]

要启用一个扩展插件 修改了 php.ini 后 systemctl restart php74-php-fpm 一直不能成功
看 journalctl -u php74-php-fpm 也没有具体信息
就一行红字 Failed to start The PHP FastCGI Process Manager.
于是打算用./php-fpm -y /etc/opt/remi/php74/php-fpm.conf 来试试能不能抓到报错信息
结果正常启动了
kill 之后再直接使用 service 文件里中 ExecStart 的设置值也成功了
service 文件很简单
看了下 EnvironmentFile 内容都是注释的 service 文件没有改动过

这可能是什么原因呢？

[thunderw]

systemctl status -l php74-php-fpm
加个-l 看看是咋了？

[azev]

@thunderw 还是没有详细信息

[root@cent79 ~]# systemctl status -l php74-php-fpm
● php74-php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php74-php-fpm.service; enabled; vendor preset: disabled)
Active: failed (Result: signal) since 日 2022-04-10 10:13:03 CST; 57min ago
Process: 24028 ExecStart=/opt/remi/php74/root/usr/sbin/php-fpm --nodaemonize (code=killed, signal=SEGV)
Main PID: 24028 (code=killed, signal=SEGV)

4 月 10 10:13:02 cent79 systemd[1]: Starting The PHP FastCGI Process Manager...
4 月 10 10:13:03 cent79 systemd[1]: php74-php-fpm.service: main process exited, code=killed, status=11/SEGV
4 月 10 10:13:03 cent79 systemd[1]: Failed to start The PHP FastCGI Process Manager.
4 月 10 10:13:03 cent79 systemd[1]: Unit php74-php-fpm.service entered failed state.
4 月 10 10:13:03 cent79 systemd[1]: php74-php-fpm.service failed.

[adoal]

FPM 自己的日志呢，比如 /var/log 下有没有 php74-fpm 之类的文件或目录。

[adoal]

交互用户和服务用户表现不一样，感觉是文件权限问题。

[NoahNye]

服务配置成和手动启动一样的用户试试，日常里这种情况很多的确是权限问题，如果还不行就要查看是否有多个不同环境了，多个配置文件了，我大概会这样排查。

[kiwi95]

有可能是 service 文件里面没有写 restart ，只有 start stop 这几个命令

[villivateur]

@kiwi95 restart 就是 stop + start

[azev]

@adoal /var/opt/remi/php74/log/php-fpm/error.log 中也没有什么有用信息
都是停止启动什么的
[10-Apr-2022 15:06:02] NOTICE: Terminating ...
[10-Apr-2022 15:06:02] NOTICE: exiting, bye-bye!
[10-Apr-2022 15:06:28] NOTICE: fpm is running, pid 24619
[10-Apr-2022 15:06:28] NOTICE: ready to handle connections
[10-Apr-2022 15:06:28] NOTICE: systemd monitor interval set to 10000ms
[10-Apr-2022 15:09:28] NOTICE: Terminating ...
[10-Apr-2022 15:09:28] NOTICE: exiting, bye-bye!

[azev]

@NoahNye
@adoal
看了下手动启动和服务启动的进程信息 用户是一样的
主进程都是 root 其他的都是 apache

真是头大了

[adoal]

看到你在水木上贴的 unit 文件了，貌似也没啥特别的。
对了，你说是要启用一个扩展插件 修改了 php.ini ，然后就不对了？是啥插件？ php 装好自带的还是另装的？ php.ini 怎么改的？

[adoal]

还有就是命令行上手启之后用 systemctl 也可以了？是持续多次启停都可以，还是要每次手启后只能用 systemctl 启一次？
多问问自己各种细节，说不定自己就找到问题了。

[adoal]

哦，不对，我看错了，是说使用 ExecStart 里的命令来启动可以，并不是用 systemctl

[naturegreen]

SELinux ？

[azev]

@adoal 新装的插件 swoole_loader 不过这几次启动失败看到前面有个错误信息 就是关于那个插件的
看来是插件的问题 但是我手动启动怎么就没有问题呢

[azev]

@naturegreen 是的 centos
新装了个 debian 虚拟机 没有这个问题了 同一个插件 so 文件

[neilyoone]

service 起服务 和 手动起服务 获取的环境变量可能是不一样的

具体以日志输出 排查.

[adoal]

对了，除了环境之外好像还有 ulimit 之类的东西也可能不一样

[Kinnice]

@azev 临时关闭 selinx 执行: setenforce 0

[azev]

@Kinnice
@naturegreen
@adoal 关闭 selinx 之后 可以了

[adoal]

呃，竟然开着 selinux 玩……遇到的大多数人装了 RH 系之后第一件事就是关 selinux ^_^

[yogogo]

@adoal 但没开 SELinux 很容易被挂挖矿，之前在谷歌云上面用的服务器 PHP 项目，关了 SELinux ，跑了一个礼拜就被挂挖矿，关端口也没有用，后来把 SELinux 开启，挖矿就停了

[adoal]

@yogogo 系统会被入侵的根本原因是有漏洞，SE 对系统的保护主要体现在即使因为有漏洞被爆栈了但可以限制服务进程被控制做其它动作的权力，把损失尽可能降低，但漏洞还是客观存在的，危险还是存在的，比如从系统层面是合法操作但会修改业务数据。所以尽管 SE 能保护系统免受某些侵害，但该修的漏洞还是要修的。

另外就是假如系统运维人员在部署应用软件时遵循 FHS 和发行版 packaging 的规范，SE 会保护得恰到好处，但很多人在没有学过规范的情况下会根据师傅传授或者网上搜来的自己乱搞一套，SE 就处处捣乱了，这时候只会开或者关 SE 就不够用，要去根据实际情况配置 context 。

所以很多习惯非规范的老司机针对初学者写的攻略往往第一件事是关 SE……而对初学者来说要玩转 SE 确实也不容易。