チラシの裏に書くと捨ててしまうので

PFエラーなのでメモリ関係のトラブルだとは思うのですが、原因はまだ分かってません。

症状としては不定期に突然ホストが赤紫色？の画面を表示して落ちてしまいます。エラーメッセージはすべてPFエラーなのですが、それに続くエラーコードは毎回異なるという状態です。

最初はESXi 4.0固有の問題かと思って色々調査していたのですが、実はESXi 3.5 から ESXi 4.0 へのアップグレードと同時にメモリも増設しており、とりあえずそっちの原因を疑っている状況です。

というのも、ESXi 4.0アップグレード当時のメモリ構成が

Slot1: CFD 2GB (A)
Slot2: CFD 2GB (B)
Slot3: UMAX 1GB (C)
Slot4: UMAX 1GB (D)

で、運用途中に突然死。
メモリ不足なのかなーと新たにメモリを追加して

Slot1: CFD 2GB (A)
Slot2: CFD 2GB (B)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

という構成で運用していたのですが、これでもタメ。
ならば(A)(B)メモリが原因かと思い、この２本を外して

Slot1: (空)
Slot2: (空)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

これだとOK。ただしこれだとメモリが足りなくて運用上支障が出るので、最初に外したUMAXの(C)(D)メモリを追加して

Slot1: UMAX 1GB (C)
Slot2: UMAX 1GB (D)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

としたら数時間でアウト。(涙)
とりあえず現在は

Slot1: CFD 2GB (E)
Slot2: CFD 2GB (F)
Slot3: CFD 2GB (A)
Slot4: CFD 2GB (B)

という構成で様子を見てます。
以前試した(A)(B)(E)(F)状態と似たようなものですが、メモリセットの位置をずらしてます。これで何も起きなければ幸せになれるんですが、私の経験上そんなハッピーエンドが待っている確率は非常に低い事も理解しております。

ちなみに被疑者である(A)(B)(C)(D)メモリは、全てMemtest86+を数回走らせてチェックしてみたのですがエラーは発生しません。なんなんだ、、、

現時点で考えられる原因は、
(1) ML115本体のメモリスロット(Slot1 or Slot2)がイカれた
(2) ML115のバグ (BIOSは一応最新)
(3) ESXi 4.0のバグ

ぐらいでしょうか。とりあえず次回同様の症状がみられたら、一度ESXi 3.5に戻して様子を見たいと思います。

海外通話にはSkype ProおよびSkype Outを利用させてもらっているのですが、残金が３００円を切ってオートチャージされる度にこんな刺激的なメールが飛んできます。
———-
あなたのアカウントはキャンセルされました
Skypeクレジットが自動的に購入され、アカウントに追加されました。アカウントからSkype名とパスワードでログインして、自動リチャージ設定の表示や変更ができます。
Skypeをお楽しみください。
Skype一同
———-

最初は120%フィッシング詐欺だと思って（笑）無視していたのですが、ふと心配になって調べてみたらどうやら本家からのメールに違いない事が分かりました。

ただ、慌てて色々調べてみたものの、別にアカウントがキャンセルされる訳でもないし、チャージも問題なく実行されているので最近は放置プレイの刑に処してはいますが、やっぱり気持ちは良くないですね。

Skype側の自動返信メールの設定ミスだと思ってはみるものの、うっかりミスにしては致命的すぎるミスなのでTwitterばりにつぶやいてみました。

しかしSkypeの情報少ないですね、、、有料サービスはあんまり流行ってないのかなあ？

何も考えずPHP5.3.xに上げたら動かないモジュール続発。
どうやら寝た子を起こしてしまったらしい。(泣)

現在認識している「問題のあるモジュール」は以下の3つ
・mecab
・php_perl
・apc （Alternative PHP Cache）

とりあえずmecab以外はパッチ当てたりベータ入れたりしてその場をしのいで見たものの、開発環境が残念な感じになってしまったのも事実。

mecabもmecab本体とPHPにパッチ当てれば動くようにななるんだが、、、

とりあえず様子をみるか。

PHPを5.3.xに上げた後、いつも流してるスクリプトでdate()関数呼び出したらこんな警告が出た。回避するには/etc/php.iniでdate.timezoneでタイムゾーンを明示するか、事前にdate_default_timezone_set()を呼ばなければならないらしい。

PHP Warning: date(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier.

オレ訳：
システムのタイムゾーン設定に依存するのは確実ではありません。date.timezoneを設定するかdate_default_timezone_set()を設定する必要があります。いずれかを設定後も引き続きこの警告が出る場合は、タイムゾーンIDが間違っている可能性が高いです。

調べたら日本のタイムゾーンIDは「Asia/Tokyo」なので、

# vi /etc/php.ini

[Date]
; Defines the default timezone used by the date functions
date.timezone = Asia/Tokyo

と設定するか、プログラム内でdate()関数を呼び出す前に

date_default_timezone_set(‘Asia/Tokyo’);

と宣言してあげてください。

ちなみにPHPでサポートしているタイムゾーンのリストはこちらで確認できます。

付録 H. サポートされるタイムゾーンのリスト

ちなみに影響範囲はPHP5.1.x以降らしいので、5.3.x固有の問題というわけではなさそう。単に俺が今まで気づかなかっただけか？