问题(已修改:使用 REPRO STEPS!)
为了重现这种情况,请使用 Ubuntu 16.04 启动一个新的 VPS(可能适用于任何 Debian 发行版,但未经测试)并按照以下说明操作:
通过实验,我将指令精简到能够重现的绝对最少的程度
apt-get install php7.0 php7.0-dev php-pear
apt-get install libsodium-dev
pecl install libsodium
echo "extension=libsodium.so" >> /etc/php/7.0/fpm/php.ini
shutdown -r 0
当我重新启动服务器时(shutdown -r 0
)PHP-FPM 已停止工作(通过以下方式确认service php7.0-fpm status
)
如果我运行service php7.0-fpm start
,它会在几毫秒内启动,没有任何问题。
我在 libsodium-php 跟踪器上创建了一个问题,希望有人可以在那里找到解决方案:https://github.com/jedisct1/libsodium-php/issues/94
问题
现在我已经缩小了问题范围,我真正寻找的是:
找到答案的方法为什么它超时了(有没有好的方法可以分析正在访问的资源或者启动时进程正在做什么?)
一种修复它的方法(是否有某种方法可以改变启动顺序以便 libsodium 最后启动,以防它是一个依赖性问题?)
最新更新
我继续研究这个问题,发现所有 PHP 都停滞了在 libsodium 库初始化期间(调用sodium_init()
)。此调用大约需要 3-4 分钟才能完成,并且在此时间过去之前,即使调用也会php -v
失败。
作为一种解决方法,我添加了以下内容/lib/systemd/system/php7.0-fpm.service
:
TimeoutStartSec=600
这导致我的 Web 服务器在重启后几分钟内返回 HTTP 状态代码 502,但最终它会再次开始工作(比手动登录并修复它更好)
我将尝试与 libsodium 和 libsodium-php 的开发人员取得联系,以找到更好的解决方案,但现在我相信我自己已经解决了这个问题:
解决方案
当某些东西在启动时没有运行,请开始调查
journalctl -u <service>
如果超时,请尝试全新安装 - 禁用所有扩展、模块、插件、删除自定义配置等。如果全新安装有效,请逐一启用,直到找到原因
如果你确实需要插件/扩展/其他任何东西,那么你可以通过修改文件
*.service
并添加来增加超时时间TimeoutStartSec=...
答案1
问题出在 libsodium PHP 扩展上。我已开始与 libsodium 开发人员沟通,以寻求解决方案。目前:
解决方案
当某些东西在启动时没有运行,请开始调查
journalctl -u <service>
如果超时,请尝试全新安装 - 禁用所有扩展、模块、插件、删除自定义配置等。如果全新安装有效,请逐一启用,直到找到原因
如果你确实需要插件/扩展/其他任何东西,那么你可以通过修改文件
*.service
并添加来增加超时时间TimeoutStartSec=...