hideishi
Forum Replies Created
-
Posts
-
Hodokamiさん
kusanagi statusの結果を貼っていただけますか。
また kusanagi nginx --showpath の結果もいただけますか。kusanagiのnginxは nginxXXX.service という名前になっており、この名前を元に /opt/kusanagi/nginxXXX/sbin/nginx のパスに変換しています。
何らかの理由でnginxのサービス名が正しくない状態になっているのではないかと思います。kenfm0411さん
現在は解消しているので dnf clean all または dnf makecache --refresh で dnf のキャッシュをクリアした上で、再度実行いただけますでしょうか。
■原因
7/22にepelでImageMagickの更新があり、新しいバージョンのライブラリlibMagickCore-6.Q16.so.8()(64bit) に変わってしまいました。また、自動的に古いバージョンは公開終了(削除)されてしいました。
KUSANAGI (PHP) が古いバージョン libMagickCore-6.Q16.so.7()(64bit) を必要とするため、依存するライブラリが見付けられないことからインストール不能になっていました。■影響範囲
AlmaLinux 9 および CentOS Stream 9
(AlmaLinux 8は影響を受けません)■対応
7/24にKUSANAGIで古いバージョン libMagickCore-6.Q16.so.7()(64bit) を提供するRPMを作成して公開しました。
これにより、依存するライブラリが存在するようになり、現在は問題が解決しています。
dnf のキャッシュが古くて更新できない場合には、 dnf makecache --refresh で dnf のキャッシュをクリアした上で、再度実行してください。ichiさん
ご指摘ありがとうございます。
kusanagi-python312-pyOpenSSL-26.2.0-1 の依存関係の指定が誤っていました。
修正した kusanagi-python312-pyOpenSSL-26.2.0-2 をリリースしましたので、再度dnf upgradeで確認ください。エラーが再度出る場合はdnfのキャッシュが残っている場合もありますので、
dnf upgrade --refreshをお試しください。saltyorangeさん
バグの報告ありがとうございます。
kusanagi-wp-plugins 20260511-1 にて対応しました。
https://kusanagi.tokyo/releases/24518/WordPressの管理画面よりKUSANAGI Pluginのメニューを選択し、「ページキャッシュ」から「advanced-cache.phpの再生成」をクリックしてadvanced-cache.phpを再生成してください。
なお、エラー等でWordPress管理画面にログインできない場合には、先に wp-content/advanced-cache.php を削除してからログインください。
terakin様
ご迷惑をおかけします。
ただ今、OpenSSL 3.5およびそれに依存するRPMの更新作業をしているところです。
Nginxのリリースを行っている最中ですので、しばらく後に再度dnf upgradeを試していただけますでしょうか。
dnfはRPMの情報をキャッシュしている場合がありますので、その場合は dnf upgrade --refresh を試してください。
アップデートに関しては https://kusanagi.tokyo/releases/ を確認ください。なお、nginx 1.25をお使いの場合はKUSANAGIのサポート対象外となります。
https://kusanagi.tokyo/releases/18715/nicoさん、こんにちは。
KUSANAGI専用プラグインのテーマアクセラレータを無効にしてみてください。
KUSANAGI専用プラグインについてはドキュメントを参照してください。
https://kusanagi.tokyo/document/kusanagi-plugin/hiroさん
AWSをお使いのこと以外には何も情報がないので詳細は分かりかねますが、
まずはAWSのコンソール等からサーバーを再起動してみてはどうでしょうか。その上でSSHで接続可能か確認し、またログイン後に kusanagi status 等で nginx が実行できているか確認してみてください。
katsunakatamisaさん
情報が少なすぎて何もアドバイスできそうにありません。
の「できるだけ多くの情報を含める」にあるように、できるだけお使いのKUSANAGIの環境の情報を収集してください。
また dnf -y update の出力結果全文も参考になるかもしれません。pandora25さん
ご指摘のとおり、kusanagi phpではphp.iniとwww.confの特定のパラメータをインスタンスのCPU/メモリ等の値に応じて自動的に変更します。
おそらく変更されたwww.confのパラメタは request_terminate_timeout ではないでしょうか。どうしても別の値で運用したい場合にはwww.confをコピーしてwww.confよりもアルファベット順で後に来るファイル名 (例えば z-www.conf) を作成し、その中の request_terminate_timeout を変更してください。
なお、php.iniやwww.confはKUSANAGIのdnf update等で更新することがあります。
これは不具合の対応や性能改善の目的でデフォルトのパラメータを変更することがあるためです。以下は10-opcache.iniを変更したケースです。
https://kusanagi.tokyo/releases/12453/上記のようにwww.confをコピーした場合には、その変更が反映されませんのでご注意ください。
以下のPHPについてもGMPモジュールを有効化したものをリリースしました。
PHP 8.2.28-3
https://kusanagi.tokyo/releases/20144/PHP 8.1.32-3
https://kusanagi.tokyo/releases/20160/saltyorangesさん
最新のPHPの以下のバージョンにおいてGMPを有効化しましたので確認ください。
PHP 8.4.8-1
https://kusanagi.tokyo/releases/20119/PHP 8.3.22-1
https://kusanagi.tokyo/releases/20127/PHP 8.2 および 8.1 についても順次対応していきます。
saltyorangesさん
フィードバックありがとうございます。
PHPのコンパイル時にGMPモジュールを有効化する件について検討します。対応時期はまだ明言できませんが、決定した際はこちらでもアナウンスします。
murodon さん
修正版をリリースしました。ご確認ください。
https://kusanagi.tokyo/releases/19410/
