ついおとついのこと、トップページに置いているカウンタのログが壊れて、なんとか適当にそれっぽく修復させたのだが、なんと今度は拍手のログが壊れてしまった。web拍手解析を開いてみたところ、拍手がすべてゼロになっており、本日の拍手に至ってはなにも表示されないという状況だった。ここで心配するのは一言メッセージはどうかということだ。拍手のログが失われたのは辛いが、一言メッセージさえ無事ならと一縷の望みをもってメッセージのログファイルを確認してみたら、綺麗さっぱりクリアされていた。そう、拍手ログのみならず一言メッセージのログも失われてしまっていた。はっきりいって、カウンタどころではなくショックだった。
ただショックを受けていても仕方がないので、web拍手CGIを確認してみることにした。チェックするのは、ファイルの排他制御がどうなっているかだ。
排他制御というのはなにかというと、例えばこの場合なら、ログファイルを開いて作業しているものがいる場合、他のものにはそのファイルを開かせないための処理だ。同時に複数のものが同じファイルを開いて書き込みをおこなうと、内容に不整合が生じることがある。この不整合の生じることを一般にファイルが壊れる、ログが壊れるなどというのだが、つまり実際にファイルが壊れているわけではなく、記録の際に望まぬ状況が発生することで情報が失われることがあるのだな。
web拍手CGIにはファイルをロックするための機能が備わっている。clapinit.cgiの44行目あたりにファイルロックのON/OFFを決めるための変数が用意されているのだが、これがデフォルトではOFFになっている。これはサーバによっては使えない(エラーの出る)こともあるflock()関数を利用しているからで、しかし可能なら是非ONにしておきたい機能ではある。
私はもちろんファイルロック機能はONにしていて、けれどそれでもファイルは壊れてしまった。それで、このファイルロックはどのようになっているのだろうと気になって、スクリプトを読んでみた。
端的に結果を告げると、特段このやり方で問題があるようには思えなかった。簡単にロックまわりを解説すると、ファイルをロックするための目印に使うファイル(デフォルトではlock.dat)にロックをかけ、これがロックされている間はログファイルや一言メッセージファイルを触らないという、そういう段取りになっている。ロックファイルにロックがかけられるのは、すべてのログが開かれる直前であり、ロックが解除されるのはすべてのログ操作が終了した後、HTMLが出力される直前だ。
普通に考えると、このやり方で特段問題は出ないと思う。ベストは、一個一個のファイル、ログファイル(log.dat)や一言メッセージファイル(mes.dat)に対しロックをかけることだが、別ファイルのロックでもってファイル操作のプロセス全体を守ろうというやり方はポピュラーな方法であるし、と、ここで私はわからなくなってしまった。
わからないままというのもなんなので、ひとつひとつのファイルに対してflock()でロックを施すようにスクリプトを書き換えて、加えてファイルの書き換えも、単純な上書きではなく、より内容が失われにくくないようなやり方に書き換えた。何度かテストをして、無事拍手のカウントもメッセージも追加されることを確認してやれやれと思ったのだが、なにぶん自分の仕事であるから不安が残る。
さて、ここで実に奇妙な話であるのだが、再びトップページのカウンタの値が0に戻っていた。さらに見てみると、フランス語のトップページに置かれているカウンタもリセットされていた。こうしたログが失われるのは決して珍しいことではないとはいえ、しかしこの二三日の間に数回、それも同日ほぼ同タイミング?に複数のCGIのログが失われるのは尋常な事態ではない。ということは、おかしかったのはサーバ? そういえば、今日はFTPの調子もなんだかおかしかったぞ。というわけで、プロバイダに確認をしているところだ。
ところで、今更そんなこというなといわれそうな気もするが、以前私の作って公開したweb拍手支援cgiはファイルのロックに関してまったく考慮がされていない。もともとが複数人が使うるような仕組みではないと思ったので、まあなくてもいいかと考えたのがその理由だが、でもやっぱりもしかしたら付けたほうがいいのかも知れないね。
というわけで、気が向いたらweb拍手支援cgiをバージョンアップさせることもあろうかと思う。期待は禁物だが、できることはやりたいと思っている。
< web拍手改造:一言メッセージコールバック機能をつける web拍手改造:改造に関するコメントレス >