/ Last updated : 2023年8月24日 nanz php8-fpm

Kusanagi8.4から8.7に更新したらnginxが無限再起動

Tagged: php8-fpm, yum history undo, ロールバック

This topic has 9 replies, 3 voices, and was last updated 1 year, 3 months ago by nanz.

Viewing 9 reply threads

Author

Posts
- 2023年8月24日 at 17:37 #1249
  nanz
  Participant
  お世話になっております。運用しているサイトのセキュリティ対策が急務となりPHPのバージョンアップ中心に作業していたところ、掲題のような状態になっています。
  
  ○作業前環境
  CentOS Linux release 7.8.2003
  PHP 5.6.23
  KUSANAGI Version 8.4.5-7
  nginx version: nginx/1.19.1
  Zend Engine v2.6.0
  
  ○実施作業
  PHPの入れ直しと各種update
  
  ○作業後
  CentOS Linux release 7.9.2009
  PHP 8.2.9
  KUSANAGI Version 8.7.12-1
  nginx version: nginx/1.25.2
  Zend Engine v4.2.9
  
  ★発生していること★
  ・kusanagi restartをかけるとnginx と php-fpmが起動＞1秒以内に終了＞また起動＞…という動作をする
  ・/var/log/nginx/error.logを見ても下のように正常な起動/終了が繰り返されている？だけで問題が見つからない
  2023/08/24 11:53:38 [info] 14641#14641: [ngx_pagespeed 1.13.35.2-0] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite.
  2023/08/24 11:53:38 [info] 14641#14641: pagespeed: rollback gzip, explicit configuration in /etc/nginx/nginx.conf:49
  2023/08/24 11:53:39 [info] 14688#14688: [ngx_pagespeed 1.13.35.2-0] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite.
  2023/08/24 11:53:39 [info] 14688#14688: pagespeed: rollback gzip, explicit configuration in /etc/nginx/nginx.conf:49
  (これを延々繰り返します)
  nginx のステータスでは以下のようにどこかのプロセスからkillが走っています
  ● nginx.service – The NGINX HTTP and reverse proxy server
  Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
  Active: active (running) since 木 2023-08-24 17:22:27 JST; 1s ago
  Main PID: 14141 (nginx)
  CGroup: /system.slice/nginx.service
  ├─14141 nginx: master process /usr/sbin/nginx
  ├─14142 nginx: worker process
  ├─14143 nginx: worker process
  ├─14144 nginx: cache manager process
  ├─14145 nginx: cache loader process
  └─control
  └─14326 (kill)
  
  8月 24 17:22:25 server systemd[1]: Stopped The NGINX HTTP and reverse proxy server.
  8月 24 17:22:25 server systemd[1]: Starting The NGINX HTTP and reverse proxy server…
  8月 24 17:22:26 server nginx[14123]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
  8月 24 17:22:26 server nginx[14123]: nginx: configuration file /etc/nginx/nginx.conf test is successful
  8月 24 17:22:27 server systemd[1]: Started The NGINX HTTP and reverse proxy server.
  8月 24 17:22:28 server systemd[1]: Stopping The NGINX HTTP and reverse proxy server…
  
  ■考えていること
  kusanagiとOSによってNGINXの管理が変わってしまい、お互いにnginxの制御を奪い合って（再起動)いる？
  php-fpmはnginxに引っ張られている？
  ■実施したら一旦サイトが表示されたこと
  ・nginx php-fpmを「何度か」 service stopする＞複数プロセスが動いていることの証左に思える
  ・nginx php-fpmをsystemctlからdisableする
  /etc/systemd/system/multi-user.target.wants/nginx.service
  /etc/systemd/system/multi-user.target.wants/php-fpm.service　に存在しない状態を確認
  ・その状態でservice start。nginx/php-fpm/db等が起動状態になるのでサイト表示可能
  ・ただしkusanagi restartするとsystemdに登録されて無限再起動になるので行えない。nginxが自動で再起動しないので、プロセス停止したら手動対応になってしまう
  
  ★質問したいこと★
  抜本的改善はどうしたら良いのでしょうか。
- 2023年8月25日 at 05:29 #1250
  cloudy
  Participant
  nanz さん、こんにちは。
  
  まずは、トップページに書かれている通り、kusanagi status の結果を添付してください。
  
  > PHPの入れ直しと各種update
  
  > ○作業後
  > PHP 8.2.9
  
  具体的にどのような作業をされたのか不明ですが、PHP を KUSANAGI で提供しているもの以外を使われていることが原因ではないでしょうか？
  kusanagi-php と php は別物です。
  サポート対象外の作業をしているような気がします。
  
  KUSANAGI 8 の PHP 8 系のサポートバージョンは 8.0.x のみのはずで、8.2.x はサポート対象外です。
  PHP 8.0.x / 8.1.x / 8.2.x 切り替えサポートは KUSANAGI 9 でのみ提供されています。
  
  KUSANAGI 8 の kusanagi php-fpm は PHP 5.6.x 系のことのはずです。
  PHP 8 系が使用されているのであれば、サービスは php8-fpm が使用されているはずです。
  
  ユーザーフォーラムの下記の内容が参考になるかと思います。
  
  PHP7よりPHP8へ移行できない
  
  また、セキュリティ対応が必要であれば KUSANAGI 9 への移行を強くお勧めします。
- 2023年8月25日 at 10:24 #1251
  nanz
  Participant
  cloudyさん
  返信ありがとうございます。kusanagi statusの結果はこちらとなります。
  
  # kusanagi status
  Profile: (管理しているサイトのうち1つのprofile名)
  FQDN: (Profileで指定されるサイトドメイン)
  Type: WordPress
  KUSANAGI Version 8.7.12-1
  aws
  
  *** (active) nginx ***
  ● nginx.service – The NGINX HTTP and reverse proxy server
  Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
  Active: active (running) since 木 2023-08-24 17:25:04 JST; 16h ago
  
  *** (active) php-fpm ***
  ● php-fpm.service – The PHP FastCGI Process Manager
  Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled)
  Active: active (running) since 木 2023-08-24 17:25:05 JST; 16h ago
  
  *** (active) MariaDB ***
  ● mariadb.service – MariaDB 10.5.22 database server
  Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Active: active (running) since 火 2023-08-22 17:46:41 JST; 2 days ago
  
  *** ruby ***
  KUSANAGI Ruby is not installed yet
  
  *** add-on ***
  
  *** Cache Status ***
  bcache on
  fcache off
  
  *** WAF ***
  off
  
  *** SELinux ***
  off (permanent)
  
  昨日から検証を繰り返しまして、以下手順でステータスを正常稼働にできることがわかりました。ただkusanagi restart（およびkusanagi nginx）コマンドだけは駄目なようです。どこかに複数プロセスが作られる原因があるのではないかと思うのですが…
  # systemctl disable nginx
  Removed symlink /etc/systemd/system/multi-user.target.wants/nginx.service.
  # service nginx start
  # systemctl enable nginx
  Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.
  
  以下サービスの設置状況です。kusanagi restartでサービス設置してもここのnginx.serviceになるものが増えていたりはしませんでした(それは当たり前かもしれませんが)
  # pwd
  /etc/systemd/system/multi-user.target.wants
  # ll
  合計 0
  lrwxrwxrwx 1 root root 44 6月 30 2022 amazon-ssm-agent.service -> /etc/systemd/system/amazon-ssm-agent.service
  lrwxrwxrwx 1 root root 37 7月 17 2018 brandbot.path -> /usr/lib/systemd/system/brandbot.path
  lrwxrwxrwx. 1 root root 39 6月 29 2016 chronyd.service -> /usr/lib/systemd/system/chronyd.service
  lrwxrwxrwx. 1 root root 37 6月 29 2016 crond.service -> /usr/lib/systemd/system/crond.service
  lrwxrwxrwx. 1 root root 42 6月 29 2016 irqbalance.service -> /usr/lib/systemd/system/irqbalance.service
  lrwxrwxrwx. 1 root root 37 6月 29 2016 kdump.service -> /usr/lib/systemd/system/kdump.service
  lrwxrwxrwx 1 root root 39 8月 22 17:46 mariadb.service -> /usr/lib/systemd/system/mariadb.service
  lrwxrwxrwx 1 root root 37 8月 22 17:46 monit.service -> /usr/lib/systemd/system/monit.service
  lrwxrwxrwx 1 root root 37 8月 25 10:16 nginx.service -> /usr/lib/systemd/system/nginx.service
  lrwxrwxrwx 1 root root 39 8月 25 10:15 php-fpm.service -> /usr/lib/systemd/system/php-fpm.service
  lrwxrwxrwx 1 root root 39 8月 22 17:46 postfix.service -> /usr/lib/systemd/system/postfix.service
  lrwxrwxrwx. 1 root root 40 6月 29 2016 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
  lrwxrwxrwx 1 root root 46 7月 17 2018 rhel-configure.service -> /usr/lib/systemd/system/rhel-configure.service
  lrwxrwxrwx. 1 root root 39 6月 29 2016 rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
  lrwxrwxrwx. 1 root root 36 6月 29 2016 sshd.service -> /usr/lib/systemd/system/sshd.service
  lrwxrwxrwx. 1 root root 39 6月 29 2016 sysstat.service -> /usr/lib/systemd/system/sysstat.service
  lrwxrwxrwx. 1 root root 37 6月 29 2016 tuned.service -> /usr/lib/systemd/system/tuned.service
  lrwxrwxrwx. 1 root root 38 6月 29 2016 vsftpd.service -> /usr/lib/systemd/system/vsftpd.service
  lrwxrwxrwx. 1 root root 38 6月 29 2016 xinetd.service -> /usr/lib/systemd/system/xinetd.service
  
  # php-fpm -v
  PHP 8.2.9 (fpm-fcgi) (built: Aug 3 2023 11:39:08)
  Copyright (c) The PHP Group
  Zend Engine v4.2.9, Copyright (c) Zend Technologies
  with Zend OPcache v8.2.9, Copyright (c), by Zend Technologies
- 2023年8月25日 at 11:52 #1252
  cloudy
  Participant
  nanz さん、こんにちは。
  
  先のメッセージにも書いた通り、KUSANAGI で提供している以外の PHP をインストールして使用しているようです。
  確認のため、PHP 8.2 をインストールした方法を教えてもらえませんか？
  KUSANAGI が提供している PHP 以外のものを手動でインストールしている場合、自己責任となりサポート対象外となります。
  
  —
  
  KUSANAGI 8 で PHP 8 系を使う場合は次のコマンドを使用します。
  
  kusanagi php8
  
  KUSANAGIコマンド
  
  KUSANAGI 8 で PHP8 での kusanagi status 実行結果の一部抜粋します。
  
  *** (active) php8-fpm ***
  ● php8-fpm.service – The PHP FastCGI Process Manager
  Loaded: loaded (/usr/lib/systemd/system/php8-fpm.service; enabled; vendor preset: disabled)
  Active: active (running) since Mon 2023-01-23 10:22:59 JST; 21s ago
  
  php8-fpm なので PHP 8。php-fpm と php8-fpm は違います。よく確認してください。
  
  php -v 実行結果。
  
  PHP 8.0.27 (cli) (built: Jan 6 2023 08:51:20) ( NTS )
  Copyright (c) The PHP Group
  Zend Engine v4.0.27, Copyright (c) Zend Technologies
  with Zend OPcache v8.0.27, Copyright (c), by Zend Technologies
  
  これが KUSANAGI 8 で PHP 8 系に正しく切り替わっている結果となります。
  
  —
  
  頂いた kusanagi status の内容を確認したところ、
  
  *** (active) php-fpm ***
  ● php-fpm.service – The PHP FastCGI Process Manager
  Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled)
  Active: active (running) since 木 2023-08-24 17:25:05 JST; 16h ago
  
  php-fpm なので PHP 5。php-fpm と php8-fpm は違います。よく確認してください。
  ですので KUSANAGI 8 は PHP 5 系を動作させようとしています。
  
  # php-fpm -v
  PHP 8.2.9 (fpm-fcgi) (built: Aug 3 2023 11:39:08)
  Copyright (c) The PHP Group
  Zend Engine v4.2.9, Copyright (c) Zend Technologies
  with Zend OPcache v8.2.9, Copyright (c), by Zend Technologies
  
  こちらをみると PHP 5 系ではなく、PHP 8 系を実行した結果が返ってきています。
  おそらく別にインストールされた PHP 8 系を動作させようとしています。
  
  なので、PHP サービスの衝突が起こっていると予想されます。
  原因は、KUSANAGI で提供している PHP 以外の PHP を手動でインストールしないと起こり得ません。
  KUSANAGI 8 で推奨していない使い方となり、サポート対象外となります。
  
  心当たりがある場合、PHP を手動でインストールする以前にロールバックして、改めて KUSANAGI 8 標準の PHP 8 系をご利用いただければ「抜本的改善」になると思われます。
- 2023年8月25日 at 16:28 #1253
  nanz
  Participant
  cloudyさん
  返信ありがとうございます。PHPの導入に用いた手順を確認いたします。
  手動導入されている場合はサーバ内に入っているPHPを一通り除去したのちkusanagi php8コマンドで手順通りの状態に戻せるものと理解できました。
  恐らくサポート外の作業をしてしまっていたと思いますが、調査いただきありがとうございます。
- 2023年8月29日 at 13:05 #1254
  nanz
  Participant
  お世話になっております。サポート対象の状況にすべく
  yum remove ‘*php*’からのyum install kusanagiとして
  クリアインストールを実施したのですが状況は悪化するばかりでした。
  
  kusanagi nginx
  kusanagi php8-fpm
  と実行した直後のkusanagi statusが以下のような状態になります。
  
  ○問題
  ＞ nginxが延々と再起動し続けます
  ＞ php-fpmがstatusに表示されません
  
  # kusanagi status
  Profile: —-
  FQDN: —-
  Type: WordPress
  KUSANAGI Version 8.7.12-1
  aws
  *** (active) nginx ***
  ● nginx.service – The NGINX HTTP and reverse proxy server
  Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
  Active: active (running) since 火 2023-08-29 12:58:50 JST; 235ms ago
  *** (active) MariaDB ***
  ● mariadb.service – MariaDB 10.5.22 database server
  Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Active: active (running) since 火 2023-08-29 12:46:29 JST; 12min ago
  *** ruby ***
  KUSANAGI Ruby is not installed yet
  *** add-on ***
  *** Cache Status ***
  bcache on
  fcache off
  *** WAF ***
  off
  *** SELinux ***
  off (permanent)
  
  [root@ip-172-31-20-37 multi-user.target.wants]# ll
  合計 0
  lrwxrwxrwx 1 root root 37 8月 29 12:56 nginx.service -> /usr/lib/systemd/system/nginx.service
  lrwxrwxrwx 1 root root 40 8月 29 12:58 php8-fpm.service -> /usr/lib/systemd/system/php8-fpm.service
  (他省略)
- 2023年8月29日 at 15:03 #1255
  yosuke
  Participant
  nanz さん、こんにちは。
  
  > kusanagi nginx
  > kusanagi php8-fpm
  > と実行した直後のkusanagi statusが以下のような状態になります。
  
  「kusanagi –help」で見て頂ければわかると思いますが、「kusanagi php8-fpm」はないかと思います。
  php8系で、動作させるのであれば、「kusanagi php8」になります。
  
  KUSANAGIコマンド
- 2023年8月29日 at 15:12 #1256
  nanz
  Participant
  yosukeさん、確認ありがとうございます。
  フォーラムへのコマンド記載間違いでした、失礼いたしました。
  実行したコマンドはkusanagi導入後
  > kusanagi nginx
  > kusanagi php8
  です。この操作の結果先の正しくないステータスとなりました
  
  なお、これはphp8-fpmが見つからなかったことでnginxが再起動していたことがわかりました。
  yum install kusanagiによってkusanagi-php7およびkusanagi-php8という形でPHPはインストールされたものの
  php-fpmが漏れていたことでkusanagi statusに出現しなかったようです。
  php-fpmの手動インストールによって一旦サイト復旧はいたしました。
- 2023年8月30日 at 13:55 #1257
  cloudy
  Participant
  nanz さん、こんにちは。
  
  コメントを見る限り、ロールバックの意味を正しく把握されていないものとお見受けいたします。
  アンインストールとロールバックは別物です。
  
  ロールバックは、その地点まで作業をもとに戻すことを指します。
  アンインストールのみでは、依存ライブラリについての考慮ができていません。
  手動で PHP のインストールなどを行っているため、ライブラリ依存関係も当然元にも戻す必要があります。
  確実なロールバックは、作業前時点のスナップショットに戻すことです。
  
  スナップショットの状態にロールバックする作業例
  https://qiita.com/takahashi-kazuki/items/23a5a7c62fc086d51909
  
  yum history undo でパッケージの導入をロールバックする作業例
  
  ロールバック (スナップショットや yum など) の話は KUSANAGI の範囲外の内容となりますので、こちらでの回答はできかねます。
  上記はあくまで参考情報です。
  ご了承ください。
- 2023年8月31日 at 19:49 #1258
  nanz
  Participant
  cloudyさん
  返信ありがとうございます。
  ひとまず現状システム重複状態を解決することができましたので報告だけさせていただきます。
  純粋にシステム導入手順の問題として社内で共有いたします。ありがとうございます
Author

Posts