hideishi
Forum Replies Created
-
Posts
-
katsunakatamisaさん
KUSANAGIプラグインが負荷軽減のために一定時間(60分)キャッシュを保持しているためです。
kusanagi update plugin の結果が即時反映されません。
60分後くらいにメッセージが残っているか再度確認していただけますか。今後、アップデート結果が即時反映されるように改善します。
kenfm0411さん
kusanagiのnginxはnaxsiを静的モジュールとしてコンパイル済です。
nginx.confのload_moduleはコメントアウトする必要はありません。
また /opt/kusanagi/nginx131/lib64/modules/ngx_http_naxsi_module.so も存在しません。
歴史的経緯から、まぎらわしい設定コメントが残っていてすみません。
なお、ドキュメントにある「初回の関連パッケージのインストール」はhttpdの場合に発生します。
nginxは上記の通り同梱なので発生しません。/etc/opt/kusanagi/nginx/conf.d/kusanagi_naxsi_core.confにコメントがなく
/etc/opt/kusanagi/nginx/conf.d/プロファイル.wp.incのinclude naxsi.d/...にコメントがなければ
有効化されています。naxsiはWordPressやPHPを通る処理にのみ設定しているので、URLやリクエストの内容によっては通らないことが考えられます。
URLがPHPファイルのパスであるか確認いただけますか。
WordPressの場合 / などのURLへのアクセスを別のURLにリダイレクトし、その際にクエリストリングが欠落することがあります。curl -i -L 不正なクエリのURLのようにHTTPヘッダを表示しつつ、リダイレクトを追うようにすると確認しやすいです。または DocumentRoot 直下に
<?phpのみの hoge.php を作って hoge.php にテストクエリを付加してみてください。kenfm0411さん
同様の原因と思われます。
存在しない nginx@ あるいは httpd@ のシンボリックリンクが残っている可能性があります。
ls -l /etc/systemd/system/multi-user.target.wants/nginx*.service
ls -l /etc/systemd/system/multi-user.target.wants/httpd*.service
リンク切れのものを削除して systemctl daemon-reload で解消します。こちらも先の修正と合わせて対応します。
Hodokamiさん
おそらく原因が分かりました。
/etc/systemd/system/multi-user.target.wants/nginx.service
にリンク切れのnginx.serviceの残骸が残っているのが原因です。
このファイルを削除していただければ解消します。リンク切れの場合でもrestartが機能するように修正します。
Hodokamiさん
kusanagi statusとkusanagi nginx --showpathに問題はなさそうですね。
kusanagi restartコマンドの異常と考えます。まず systemctl restart kusanagi でkusanagiサービスをリスタートしてみてください。
何らかの理由で古い kusanagi のモジュールのまま動作している可能性があります。それでも解消しない場合は
/var/opt/kusanagi/log/kusanagi/backend.log
にログが出ていると思われますので、最後のエラーあたりのログをいただけますでしょうか。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をコピーした場合には、その変更が反映されませんのでご注意ください。
