bcache on時に「WP_CACHE定数が重複して定義されています」となり失敗します。

TOP Forums その他(Everything else KUSANAGI) bcache on時に「WP_CACHE定数が重複して定義されています」となり失敗します。

bcache on時に「WP_CACHE定数が重複して定義されています」となり失敗します。

Viewing 12 reply threads
  • Author
    Posts
    • #61
      sumito
      Participant

      kusanagi bcache on
      をすると

      onにします。
      失敗しました。WP_CACHE定数が重複して定義されています。
      完了しました。

      となり失敗で完了します。
      wp_config.phpや様々な場所を確認しましたが、
      どこにも定数のようなものを見つけることができませんでした。
      kusanagi statusで確認しても、bcache、fcache共にoffの状態です。
      bcacheやfcacheのclearやoffなどもしていますが変わりません。

      どのような状態の際に上記のようなエラーが出るのでしょうか?

    • #62
      しょうくん
      Moderator

      sumitoさん、こんにちわ!

      通常WordPressでKUSANAGIが用意しているPHPベースのページキャッシュを使用する場合、
      wp-config.php に define(‘WP_CACHE’, true); の記述が必要となります。
      ただし、デフォルトのKUSANAGIの場合、この記述がコメントアウト状態で #define(‘WP_CACHE’, true); のように記述されており、このコメントをKUSANAGIコマンドで取ったり付けたりすることでキャッシュのON/OFFを制御しています。

      ですので、この記述が例えばコメントアウトの記述とコメントアウトされていない記述が両方あったりすると、コメントアウトをKUSANAGIコマンドで外そうと試みた際に定数の重複を検知します。
      通常ですと wp-config.php はWordPressのインストールディレクトリ(例えば、/home/kusanagi/<作成したプロファイル>/DocumentRoot/)に存在しているはずですので、その中の /* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */ というコメントの直前くらいにあるはずです。

      よくあるのが、KUSANAGIを導入後にWordPressを移設した際、wp-config.phpもコピーして移植してしまった場合にこのコメントアウト部分がなくなっていることが考えられます。
      kusanagi provision で作成した時の wp-config.php ファイルが残っていればそちらを参考に改修すると正常にどうさするようになるかと思いますよ。

    • #63
      sumito
      Participant

      しょうくんさん、ご回答ありがとうございます!

      wp-config.phpはkusanagiによって用意されたものをそのまま使用しているのと、
      WP_CACHEに関する記述はコメントアウトされているいない関わらずそもそも存在していないのです。

      ただ、そもそもコメントアウトされているものすら存在しないことがおかしいというのがわかったので、
      コメントアウトした状態ものを追記してから kusanagi bcache on を実行したらonになりました!

      コメントアウトされたWP_CACHEが存在しなかった原因として想定されるのは、
      実は一度bcacheをonにしてそのあとfcacheもonにしていたことがあり、
      その後、別で問題が発生した際にoffにしようとしたらbcacheだけoffにできず、
      その後、onにもできなくなってしまったという状態です。
      fcacheを先にoffにしてはいけないなどがあるのでしょうか。

      とりあえず問題は解決いたしました。
      ご回答ありがとうございました!

    • #64
      sumito
      Participant

      しょうくんさん

      後追いですみません。
      よく確認したら解決していませんでした。

      たしかに先ほど書いた方法でkusanagi bcache onのコマンドは成功した(エラーは出ずに完了した)のですが、
      wordpressの管理画面を確認すると、
      「ページキャッシュは有効になっていません。有効にするには、仮想サーバのコンソール上で、 kusanagi bcache on と入力してください。」
      の状態のままだったので、おかしいなと思いwp-config.phpを確認すると、
      WP_CACHEのコメントアウトは外れていませんでした。

      その後、kusanagi bcache onやoffを繰り返してみましたが、
      コマンド自体はエラーにはならないのですがwp-config.phpは全く書き換えられず、何の変化も起きません。
      (ただ、wp-config.phpのタイムスタンプだけがなぜか更新されている。。)

      そこで手動でコメントアウトを外してみたのですが、
      それでもキャッシュ機能はonにはなっていないようです。
      それと、kusanagi bcache onすると「完了しました」となるのですが、
      kusanagi statusで確認してもbcacheはoffのままであることも確認できました。

      この状態はどういう状態なのでしょう。。

    • #65
      しょうくん
      Moderator

      fcacheはNGINXのキャッシュでwp-config.phpを利用していないので、bcacheだけがwp-config.phpの書き換えを行いますので、どちらを先にON/OFFしてももちろんどちらかだけを使用していても問題はありませんね。

      何らかの操作時か、KUSANAGIのprovision時に定数が設定されなかったか消えてしまったのでしょう。
      ないとは思いますが、KUSANAGIの専用プラグイン以外にキャッシュ系のプラグインを入れていたりしませんよね?

    • #68
      しょうくん
      Moderator

      可能性としてはいくつか考えられます。
      ただ現状を把握するために kusanagi status の内容を張り付けてもらえると良いかもしれません。

      考えられることは複数 provision していて、ターゲットが変わっている場合ですね。
      kusanagi target で現在のプロファイルの確認と変更ができます。

      複数provisionしていないとなるとKUSANAGIのバージョンなどの問題なども出てくるかもしれません。

    • #69
      sumito
      Participant

      しょうくんさん

      度々のご回答誠にありがとうございます。

      他のキャッシュプラグインは動いていません。
      kusanagi statusの結果を貼り付けます。

      ============================
      Profile: /*正しく運用中のドメイン(ディレクトリ名)が出力されていました*/
      Type: WordPress
      KUSANAGI Version 8.0.2-1
      conoha

      *** 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 土 2016-12-17 16:55:58 JST; 19h ago

      *** Apache2 ***
      ● httpd.service – The Apache HTTP Server
      Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

      *** HHVM ***
      ● hhvm.service – HHVM virtual machine, runtime, and JIT for the PHP language
      Loaded: loaded (/etc/systemd/system/hhvm.service; enabled; vendor preset: disabled)
      Active: active (running) since 金 2016-12-16 17:27:35 JST; 1 day 19h ago

      *** php-fpm ***
      ● php-fpm.service – The PHP FastCGI Process Manager
      Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

      *** php7-fpm ***
      ● php7-fpm.service – The PHP FastCGI Process Manager
      Loaded: loaded (/usr/lib/systemd/system/php7-fpm.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

      *** Cache Status ***

      fcache off
      bcache off
      完了しました。
      ============================

      kusanagi targetは、
      kusanagi statusのProfileの値が正しく出力されていました。

      kusanagi targetの値は確かに現状のprofileを示していましたが、
      provisionを複数したという件については心当たりがあります。。
      同じ名前でprovisionをしてしまったことがあります。

    • #71
      しょうくん
      Moderator

      複数provisionを行ったと言うことですが、現状 kusanagi status の内容を見る限りはバージョンも最新ですし問題があるようには見受けられませんので、念のため以下を確認してみてください。

      1. /homu/kusanagi/ 以下に現在のprovisionしたディレクトリ以外が存在するか。
      2. /etc/nginx/conf.d/ に現在のprovisionした <profile>_http.conf 及び <profile>_ssl.conf だけが存在するか。

      現在実行されているプロファイル名と上記ディレクトリ及びconf設定名が合っているか確認をしてみましょう。
      また、 cat /etc/kusanagi.conf した時の中身 PROFILE=”<profile>” が正しいかも確認してみましょう。

    • #72
      sumito
      Participant

      しょうくんさん

      度々お手数おかけして申し訳ございません。

      >>1. /homu/kusanagi/ 以下に現在のprovisionしたディレクトリ以外が存在するか。

      存在します。
      指定したprofileのディレクトリともう一つ、
      <指定したprofile>_oldというディレクトリがあります。

      >>2. /etc/nginx/conf.d/ に現在のprovisionした <profile>_http.conf 及び <profile>_ssl.conf だけが存在するか。

      こちらは、それらprofileのもの二つの他にも、
      _http.conf
      _ssl.conf
      http.conf
      ssl.conf
      という4つのファイルがありました。
      (正しいものを含めて合計6つのファイルが存在)

      >>また、 cat /etc/kusanagi.conf した時の中身 PROFILE=”<profile>” が正しいかも確認してみましょう。

      こちらは正しい値が設定されていました。

    • #73
      satoru
      Moderator

      横から失礼します。
      以下のコマンドの結果を教えてください。

      grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php

      初期状態では以下のようになるのが正常です。

      > grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
      #define('WP_CACHE', true);

      bcacheの使用時には以下のようになるはずです。

      kusanagi bcache onの例)

      > kusanagi bcache on
      onにします。
      完了しました。
      > kusanagi bcache 
      bcache は有効です
      完了しました。
      > grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
      define('WP_CACHE', true);

      kusanagi bcache off の例)

      > kusanagi bcache off
      offにします。
      完了しました。
      > kusanagi bcache 
      bcache は無効です
      完了しました。
      > grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
      #define('WP_CACHE', true);
    • #75
      sumito
      Participant

      satoruさん

      grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
      の結果は下記の通りです。

      #define(‘WP_CACHE’, true);

      こちらは先ほども書いていますが、元のwp-config.phpには入っていなかったので、
      私が独自に追記したものです。

      また一連のkusanagi bcache onの結果についてですが、
      こちらも前に書いている通りで、
      kusanagi bcache onをした後も、
      grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
      の結果は下記の通りです。

      #define(‘WP_CACHE’, true);

    • #76
      satoru
      Moderator

      表示上の都合かもしれませんが、貼り付けていただいた部分の「’」の文字がいわゆる半角文字になっていないようです。
      念のため、実機で半角文字になっていることをご確認ください。

      od コマンドで確認すると、以下のように表示されるはずです。「’」の上の数字が27になっていない場合、
      半角文字ではないことが考えられます。
      その場合、vi コマンドなどで、「’」の部分を手動で置き換えてください。

      > grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php | od -tx1 -c
      0000000  23  64  65  66  69  6e  65  28  27  57  50  5f  43  41  43  48
      #   d   e   f   i   n   e   (   '   W   P   _   C   A   C   H
      0000020  45  27  2c  20  74  72  75  65  29  3b  0a
      E   '   ,       t   r   u   e   )   ;  \n
      
    • #77
      sumito
      Participant

      satoruさん

      ご確認頂きまして誠にありがとうございます。

      こちら半角文字ではないことが問題だったようです。
      入力時には半角以外のものを使ったつもりはなかったのですが。。
      半角に置き換えて再度bacache onにしたところ、正しくonになりました。

      本当に助かりました。
      この度は詳細なご確認を頂きまして誠にありがとうございます。

Viewing 12 reply threads
  • You must be logged in to reply to this topic.

Next article

フォーラムについて