XREA & CORESERVER の cron と WordPress の wp-cron

UNIX 系の OS には cron と呼ばれる、コマンドのスケジュール実行機能が備わっています。 基本的には UNIX のコマンドを指定された時期に呼ぶだけの機能なので、実行可否によって次の実行分岐をしたりするジョブスケジューラ的なことをするには不向きですが、簡単な定期実行くらいなら便利に使うことができます。

最近のレンタル Web サーバでは、この機能をユーザに提供しているところも多く、特にスクリプト系の Web アプリケーションのような、ユーザのアクセス契機でしか動作しないプログラムを補完する役割で cron が使われているようです。(RSS リーダの RSS 定期取得とか)

また、我らが WordPress には、この UNIX の cron とは別に、コアに wp-cron と呼ばれる(?)一連のファイルで、cron の擬似的な実装が含まれています。 ではとりあえず、WordPress の wp-cron のことから書いてみます。

WP-Cronは動いてるのか? « MMRT daily life

TB多重送信防止のため、Google XML Sitemapsをバックグラウンドで動かす設定にしたわけだが、今日確認すると投稿前日に生成されたままだ。よくわからないのだが、投稿ボタンをクリックしてから一体何秒後、何分後、何時間後に作動するのか? はたまた作動しているが失敗しているのか? 疑問は尽きない。

まずは、wp-cron の基本的な動作原理から。

一般的なスクリプト系の Web アプリケーションというのは、動作の契機がユーザによるブラウザアクセスにより始まります。 その動作は継続することはなく、ユーザのアクセス終了(画面描画)となれば、そのアプリケーションはメモリから消滅します。

てなわけで、プログラム動作が持続しないため、定刻動作などはできないわけなのですが、これをなんとか擬似的に再現したのが wp-cron です。

  • スケジュールしたい仕事があったら、とりあえず、いつ起動するのかとかなにを動かすのかとかを WordPress DB に登録。
  • ユーザからの WordPress へのアクセスがあったら、必ず上記 DB を参照して、いまやるべきことがないかを確認して、あるならサイト表示とついでにバックグラウンドで実行。

という動きです。

・・・お気づきかと思いますが、きっかけはユーザからのアクセス、ブラウザによる閲覧ですので、もし仮にそのサイトがその後1アクセスもなければ、いっくらスケジュールしておいてもなにも実行されません。 🙂

wp-cron は、遅延したスケジュールがあれば一気にそれを実行しようし、「遅刻はするけどいつかは実行してやっか」「まぁ1秒間に1回のアクセスはなくても、10分に一回くらいのアクセスならどこのサイトでもあるだろ」くらいの思想で実装されています。

ちなみに、wp-cron の時間の指定の仕方はいくつかありますが、Masayan さんが使われている Google XML Sitemap とか、ぼくのつくった wp-lwSitemap とか、コア標準のトラックバックの送信機能であるとかは、"次の誰かのアクセス" というスケジュールの仕方をしています。

また、cron の特徴とは違いますが wp-cron によるアクションの"実行"は、ちょっと特殊な方法がとられていて、ユーザの閲覧のプロセスとは別のバックグラウンドで動くようにつくられています。 要は閲覧する人の実行動作が重くなったりはしないようになっています。

これは閲覧プロセス(PHP)から、 cron ジョブ実行プロセスを司るファイルにたいして、"socket を一瞬つないで"、あたかも PHP をブラウザと同様にアクセスしてきた別ユーザのように偽装して動作しています。 PHP くんがいくら待たされても、だれもいらいらしないってことですね。(レンタルサーバ管理者はいらいらする?(笑)

また、このようにすると閲覧プロセスと cron ジョブが平行して動作をするため、閲覧 + cron ジョブと続けて実行するよりも、メモリ等のリソースを各プロセスがサーバから多く取ることができるという特徴もあります。(なので多くのエントリを持つサイトで Google XML Sitemap をバックグラウンド設定するとうまく動作するときがある。 これは昔の Google sitemaps のひろまさハックの動作と同様)

このように wp-cron は若干 hackish。 本家 UNIX cron が使えるのならば、時と場合によってそちらを使ったほうがいい場合もあります。

じゃーってことで、XREA & CORESERVER における 本家 cron の設定の仕方を紹介してみます。 他のレンサバでも同じような物だと思います。

WP-Cronは動いてるのか? « MMRT daily life

しかし、XreaはCRONが使えるじゃろ?と言われるだろうが、CRONジョブの設定ってどうするのさ? 相対パスで入力するところに例のURLをそのまま入れても使えないんじゃね?と思ったから。知ってる人がいたら教えて欲しいなぁ。

普通の UNIX のコマンドの cron の定期実行ってのはわりといろんなところに書かれているので、ここでは Masayan さんのやりたいような PHP などの Web アプリの定期実行の方法を書いてみます。

まず cron が実行できるのは、UNIX でいうところの実行ファイルです。 Windows でいえば、 .exe ファイルですが、UNIX 的には実行権限のついたファイル。 FTP でおなじみの、 700 とか 707 とか 7 が付いたファイル。(というと語弊があるかもしれないが、そんな感じです)

じゃー、実行したいのが .php のファイルなのでそれに 707 つけて指定してあげればいいかというと、これは残念ながらダメです。 .php のファイルを解釈できるのは、PHP のインタープリタだけだからです。 cron に指定するのは、UNIX が解釈できる実行ファイルでないとだめであります。

PHP のインタープリタって何?って話ですが、これは簡単で、php ってコマンド。

php -f hogehoge.php

ってうつと、hogehoge.php が実行されます。 cron の場合は、フルパスで指定しなければならないので、 /usr/bin/php とかになるんかな。 で、その後ろの hogehoge.php もフルパスにすればいけるはず。。

めんどくせ!

おまけにこれは動作確認しずらいので、ここでは別な方法を書いてみます。

UNIX の実行できる(cron に登録できる)ファイルにシェルというのがあります。 これをまずサーバ上におきます。 ワンクッションおきこのシェルに動作手順を書いて、cron に実行してもらいましょう。

これは、ユーザに閲覧される必要がないファイルなので、public_html より上のディレクトリにおきましょう。 たとえば、cron ってディレクトリをつくる。

Image2

で、その中に以下のようなファイルをつくります。 ファイル名は何でもよく、拡張子は一般的には .sh。 必ずアスキーモードで FTP 転送し、権限を 700 に指定。

fetch.sh (実際のファイルに行番号はいりません)

   1: #!/bin/sh
   2:  
   3: cd /virtual/[ユーザ名]/cron/
   4: wget http://[実行したい.phpのURL] -O result

[ユーザ名]と[URL]は適宜変更のことです。

wget というのは、コマンドラインの http クライアントです。 .php はブラウザでアクセスされると動くので、UNIX のコマンドラインブラウザ(?)で定期閲覧してあげるわけです。(上で書いた php -f でもいけるかと思いますが、UNIX パスより wget の http 表記のほうが分かりやすいかと思いこうしています)

でもって、レンタルサーバの cron 設定画面で、この .sh をフルパスで指定。

Image5

cron/fetch.sh

時間はお好みで設定してください。 上の例は毎時 0 分に実行。これで、 http://[実行したい.php のURL] のスクリプトが定期実行されます。

また、実行結果がメール通知され、 cron/ ディレクトリには毎回 result とかってファイルができるはずです。(この辺は各自調整してください)

これで cron の設定ができるようになりました。 cron が使えるようになると、 MySQL の定期バックアップとかもできるようになるので、興味があればやってみてください。 🙂

うわ、なげー。。 以上、wp-cron と cron の説明でした。(オチはない

このエントリーをはてなブックマークに追加
  • xdebug03.png
    Ecipse PDT 3.5 + xampp + xdebug を使った PHP デバッグ
    xdebug, デバッグ, php, PDT, ブレイク, 設定, 1.7.3, Eclipse, PHP, xampp, URL, XAMPP, 動作, WP, WordPress, ini, セッション, デバッガ, ファイル, ブラウザ
  • otenki_admin1.png
    WordPress 徹底解析(まとめ)
    WordPress, 拡張, 解説, API, php, 情報, お天気, コード, ソース, 動作, 実装, フック, 出力, 取得, 画面, ファイル, 処理, 機能, 管理, 記事
  • jrelated05.png
    wp-jrelated 1.52 リリース (関連取得不具合修正)
    URL, デバッグ, 場合, 画面, アップデート, バージョン, ブレイク, 方, 管理, 関連, WordPress, 変更, 1.52, WP, エントリ, デバッガ, プラグイン, ポイント, 不具合, 修正
  • wp3202.png
    WordPress を dotCloud にデプロイ
    dotcloud, mysql, WordPress, サーバ, PaaS, アプリケーション, dotCloud, wp, デプロイ, PHP, com, create, ever, maple, アプリ, サービス, ファイル, OS, info, install
  • aptana21.png
    Aptana Studio と DB 開発統合
    DB, Eclipse, データベース, Aptana, MySQL, SQL, 接続, 開発, JDBC, jar, 統合, 設定, Connector, Plugin, for, ファイル, 便利, 環境, 選択, DBViewer

XREA & CORESERVER の cron と WordPress の wp-cron” への16件のコメント

  1. 1個人のため?にわざわざご説明をありがとうございます。(苦笑)

    あぁそうすればいいんですね。
    よくよく考えるとサーバのアクセスログを見るのにawstatsを入れているのですが、毎日実行するのに***.shをCRONで叩いてました。(汗)

    以上、まったく応用力のないMasayanでした。(情けねー)

  2. Masayan さん、こんにちは。 😀

    >よくよく考えるとサーバのアクセスログを見るのにawstatsを入れているのですが、毎日実行するのに***.shをCRONで叩いてました。(汗)

    おーまさに! その .sh の後ろの行にに sitemap も追加すると楽かも知れません。ただ .sh の実行時間制限あったはずなので、時間かかりすぎると XREA に落とされるかも。。 その場合は別時間、別 .sh のほうがいいかもしれません。

    Sitemap ができたりできなかったりする問題はおそらくは、サーバのリソース不足です。 深夜とか空き時間帯をねらって cron するとたぶん大丈夫なんじゃないかな~って想像しています!

  3. ピンバック: Slashcolon /:

  4. ピンバック: ブログを自宅サーバーからさくらに移動 - 進・日進月歩

  5. ピンバック: マゼランな航海

  6. ピンバック: 井本健のいもけん日記 - さくらインターネットのサーバとCakePHPでcronを使う方法をすこし変えてみた。

  7. ピンバック: Hello WordPress!» ブログアーカイブ » wpのバックグラウンドで動くpingの仕組み(wp-cron)

  8. ピンバック: WordPress メモ - no subject

  9. ピンバック: Hinemosu

  10. ピンバック: MMRT daily life

  11. ピンバック: XREA & CORESERVER の cron と WordPress の wp-cron » M notebooks

  12. ピンバック: 2010/05/19に気になったこと | debeso

  13. ピンバック: Bookmarks of This Week (6/27-7/4) - Sometime PHP

  14. ピンバック: トラックバックを失敗しにくくする - Good Harvest

コメントを残す

メールアドレスが公開されることはありません。