hideishi
Forum Replies Created
-
Posts
-
kusanagi statusとログの提供ありがとうございます。
kusanagi statusの結果からはmariadbが正常に起動しているので、initに問題はなさそうです。
そのままprovisionできるのではないかと思います。今回実行されたinitは初回のinitではなく、2回目以降のinitの実行ですね？
再度initを実行しても同じになるか確認ください。
それでもダメならば kusanagi dbinit mariadb を実行してみてください。
それでも解決しない場合はVMを作り直す方が早いと思います。こんにちは。
kusanagi statusの情報がないので憶測で書きます。
kusanagi initの中でMariaDBのインストールをする処理で止まっているものと思われます。
その場合、ここ数日はMariaDBのリポジトリへのアクセスが不安定だったのでその影響が考えられます。
時間をあけて再度試してみてはいかがでしょうか？
また /var/opt/kusanagi/log/kusanagi.log の中身を見ることで詳細が分かるかもしれません。WEXALはPHP7以上が必須なので、PHP5.6では動作しません。
php-fpmサービスは PHP5.6 です。
PHP7 は php7-fpm サービスになります。タイムアウト時間を変更した際に、誤って php7-fpm の代わりに php-fpm を起動したのではないでしょうか？
KUSANAGIコマンドも kusanagi php は PHP5.6 で、PHP7 は kusanagi php7 です。
kusanagi php7 を実行して、PHP7に戻してください。なお、PHP7のiniの場所はPHP5.6と異なるので、タイムアウトの設定を変更している場合は同じものを
PHP7にも設定してください。/etcのディレクトリ名で判断できると思います。無効にできていないようですね。
optimized_wp_settings.php が残っていたら手で削除してみてください。
また、wp-config.phpを以下のように修正してください。/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');本来ならば
/** Sets up WordPress vars and included files. */
if ( file_exists( ABSPATH . 'optimized_wp_settings.php' ) && ( ! defined( 'WP_CLI' ) || constant( 'WP_CLI' ) !== true ) ) {
require_once(ABSPATH . 'optimized_wp_settings.php');
} else {
require_once(ABSPATH . 'wp-settings.php');
}にあるように optimized_wp_settings.php か wp-settings.php のどちらかしか読み込まれないはずなのですが、
プラグインかテーマか何かが干渉しているのか、media.phpが二重に読み込まれているのがエラーの原因です。kuorda さん、こんにちは。
wp-settings.phpの最適化はかなりピーキーな最適化を行うオプションです。
プラグインやテーマによっては動作しない場合がありますので、
もしも表示に問題が出るならば無効にするようにしてください。PHP 8.0以降で採用されているJITコンパイラによる最適化をできるだけ受けられるように
optimized_wp_settings.phpを生成します。
ただ、このファイルの生成は管理画面で有効化したときにのみに行われるので、
WordPressのアップデートやプラグイン、テーマの更新があっても更新されず、
このファイルを削除して再生成する必要があります。
有効にしてからしばらく時間が空いている場合は、これが原因の可能性が高いです。なお、PHP8.0以前の場合はあまり改善効果は見込めません。
アップデートの際には注意事項がある場合があります。
リリース情報も確認ください。モジュールのアップデートについては、以下のコマンドで適用可能です。
# yum update --enablerepo=remi,remi-php56
php8を使用している場合は以下のコマンドで再起動してください。
# kusanagi php8
以下を見てください。
Q5. yum のアップデートを実行すると、エラーが出力されてアップデートできません。
A5-2. 以下のようなメッセージが出力された場合、パッケージ依存性の処理において remi パッケージを必要とすることがあります。
エラー表示の例
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest問題を回避するために --skip-broken を用いることができます。
これらを試行できます: rpm -Va --nofiles --nodigestkusanagi 9 init ができないです。
コマンドは以下、init自体はよくやるやつなので、問題はないはずなのですがそのinitに失敗しています。
おそらくはnginxのインストールが完了していないと思います。
kusanagi statusを見るとnginxがいないのではないでしょうか。kusanagi initをした際のログを貼っていただけますか？
nginxのインストールが失敗している場合、
kusanagi nginx --use nginx121 などでnginxだけ入れ直すと解決します。こんにちは
kusanagi-php7のアップデートでは --enablerepo=remi が必要です。
`
# yum update kusanagi-php7 --enablerepo=remi
# kusanagi php7
# yum update kusanagi
`こんにちは
kusanagi init に --ruby26 を指定したときに、phpが正しくインストールされないのが原因だと分かりました。
今は動作していると思いますが、一応以下のコマンドを実行しておいてください。
phpインストール時の行うはずの処理を実行します。kusanagi phpこんにちは。
モジュールが最新になっているか確認いただけますか？
dnf update -y特にkusanagi-openldapが最新になっていない可能性が高いです。
最新は以下です。dnf list --installed | grep kusanagi-openldap kusanagi-openldap.x86_64 2.5.7-1.el8 @kusanagiこんにちは。
PST ManagerからURLを指定してdelayから除外する方法はなさそうです。力技になってしまいますが、pst.config.yamlのファイルを直接編集する方法ならあります。
試しに1つ何か「/wp-content/cache/autoptimize/css/ほげほげ.css」を除外して、本番化してみてください。
そうすると、pst.config.yamlにそのURLがあるはずです。(shorten urlで _wt になっているかもしれません)
そこを「/wp-content/cache/autoptimize/css/.+.css」と正規表現に置き換えることで、『/wp-content/cache/autoptimize/css/ に含まれるファイル』という条件と実現できます。
ただし、手動で編集するとPST Managerからはマニュアルモードと見なされて、PST Managerから編集できなくなってしまうのでご注意を。ちなみに、Autoptimizeの機能はWEXALの機能と重複する部分が多くあります。
デザインが崩れるのもその影響と思います。
WEXALを使うならば、Autoptimizeをoffにするのがいいと思います。LEONさん
有料版では、初回起動時にkusanagi init相当のことが行われていますので、kusanagi initは不要です。
kusanagi_htmlに変えて別のプロファイルをプロビジョニングしたいのであれば、
LEONさんの書かれたとおり、「3. 初期設定画面でWordPressの起動設定」をやらずに
kusanagi init, kusanagi provision profile名, kusanagi target profile名を実行でよいと思います。「3. 初期設定画面でWordPressの起動設定」の手順でセットアップした後であっても、
kusanagi remove -y kusanagi_htmlでデフォルトのプロファイルを削除して、
kusanagi provision profile名、kusanagi target profile名で作成することもできます。
