昨天下午, 趁公司流量較少時,  就停機把 PostgreSQL 資料由舊的主機 dump 下來, 再 restore 到新的主機上頭, 反正要做這個動作, 就順便把 PostgreSQL 由 8.0.3 升級到 8.2.1 (真麻煩, 每次要升級就要做一次這樣的動作, dump 加上 restore 的時間, 隨著資料變多就愈來愈久, 目前可能都要兩小時以上).

等資料弄好後, 把 ip 換掉, 就直接取代原本的主機開始運作了.

原本以為一切都正常, 但是... 晚上九點被 MIS 的人通知, 似乎 cron 裡頭的 job 都沒跑. 我上來查了兩個小時, 只發現, cron 有去執行, 但是 php script 似乎又沒有動作. 而我們手動去跑, 又都很正常. 就是透過 cron 去跑時, 好像完全沒有動作一樣.

查了一個小時, 發現那個 php script 應該有被執行到, 因為所使用的 lock 檔案日期會隨著 crod 的執行而改變, 可見 cron 的確有執行那個 php script. 但是... 後續的動作完全沒有, 連本身的 log 都沒有記錄原因.

接著開始改程式, 也把這個 job 改成每分鐘都去跑, 然後用一些 echo 把訊息寫出來, 導到 /tmp 下頭的檔案, 也把 error_reporting() 設為 1. 發現... 居然是一開始的 pg_connect() 找不到. 可是.... 明明就有 pgsql.so, 也有載入, 至少... 我們登入後直接去跑那個 php script, 完全都正常, 不會有這個錯誤. 就唯獨用 cron 跑會有問題?

後來在程式最前頭, 加上這一段自己載入看看:

if (!extension_loaded('pgsql')) {
  echo "pgsql.so not loadded\n";
  dl('pgsql.so');
} 

果然透過 cron 跑, 會跑進裡頭, 並沒有載入 pgsql.so, 接著 dl() 要載入 pgsql.so 時, 終於看到錯誤的原因了.... 會去找 /usr/lib/php4/pgsql.so 這個檔案. 但是... 我們目前的系統是會去找 /usr/lib64/php4/pgsql.so 這個檔案.

為什麼透過 cron 就會找不同路徑呢? 後來想到, 會不會是 php.ini 寫錯呢? 可是...  /etc/php.ini 看起來是正確的, 且... 我們手動去跑也的確沒有這個問題.

接著... 用 find 找了一下 php.ini, 終於看到在使用者的 home directory 裡頭有一個 php.ini, 打開一看, 果然是指到 /usr/lib/php4.... 把這個檔案刪除後, 果然 cron 裡頭跑的 php script 就正常了.

目前問題是解決了... 但是... 為什麼在使用者的目錄的 php.ini 會影響到 cron 跑的 php 呢? 又為什麼我們用同樣的使用者登入後, 再去執行就不會有問題呢? 猜測是 php 會優先載入目前所在目錄的 php.ini, 而我們登入後去執行, 都是切換到該 script 的目錄再去跑, 但是 cron 裡的動作是直接在那個使用者的目錄去跑, 所以會載入到不正確的 php.ini.

總之... 除了系統的 /etc/php.ini 外... 最好不要有其他的地方也放 php.ini, 以免發生同樣的問題吧.