SC430のうろ覚えSC430のうろ覚え最終更新:ハードディスクにトラブル発生!・・・fsckサーバプログラムのアップデート・・・apache2,PHP自動終了&復帰SC430インデックスハードディスクにトラブル発生!メモ無し&焦り&かなりうろ覚え&再現できない内容なので、信頼性に欠けています。計画的な停電だったはずがゴールデンウィークに電源設備のメンテナンスで停電になるので、サーバを含めた全ての機械の電源を落とすことになった。わけで予定時間にサーバの電源を落とす役に。予定時間になったのでサーバの電源スイッチを片っ端からホイホイ、ホイッと押していった。全て電源ボタンでシャットダウンできる。ついでにUPSもメンテナンスしたかったので、しばらくしてからUPSの電源スイッチを切った。あれっ?しまった!何だ?今の音?「パチン」はUPSのスイッチの音。「カチッ」は?・・・第2サーバ?!。電源入ってた?(汗)ディスプレイが別のサーバに切り替わっていた(か、ディスプレイの電源を切ってあった)ので気がつかなかった・・・。・・・とりあえず・・・電源を入れなおしてみる。OSの起動は・・・OK。いや、ファイルシステムの初期チェックでやっぱり同期が取れていない(書き込みキャッシュが正常に書き込まれていないような感じ?)らしい。起動はできて、バックグラウンドでファイルシステムのチェックをしているようだ。アクセスも無い時間だし作業中というわけでもなかったから様子を見てみるか。パニック!と、思っていたら、カーネルがパニックしました。何かキーを押すと再起動します。(脂汗)とりあえず・・・頭の中には再起動しかなかった。前回と同じようにファイルシステムの初期チェックで引っかかって、バックグラウンドでファイルシステムのチェックをしている。思っていたらまたパニックが。今度はタイピング中だったのでメッセージの確認も出来ずに再起動してしまった。その後も同じようにパニックが出た。原因は?最初パニックになった時はちょうどUSBキーボードを切り替えた時点だったので、USBのプログラム関係だと疑っていたのだが、最終的にはメッセージに自作のプログラムの名前が載っていたので、たぶんそれだろうと思った。自作プログラムは図面データディレクトリを探索してファイル名や図面情報を収集するためのもの。crontabに登録し、数分間隔で自動実行していた。このままではまたパニックになって再起動する羽目になるので、そのプログラムの自動実行を止めた。・・・その後パニックにならなくなったので、どうやらビンゴだったらしい。ファイルシステムは?とりあえずファイルシステムがどのくらいダメージを受けたのかわからないので、ファイルチェックをしようと・・・はて、どうやってやるんだっけ?。fsckだったかな?。おっと、バックグラウンドのチェックが終わってからのほうがよさそうだな。fsckえっ?自動的に全てのマウントポイントの検査が行われているようなのだが、なんかやたらと不整合が見つかっているのにも関わらず、修正しない&修正するかどうかの確認もなく終わってしまった。システムが使用しているファイルシステムだからかなぁ?そうだったらいいんだけど。FIXITからシェルを呼び出す。/dev/ad1s0aデバイスを指定してfsckを使ってみる・・・が、なんやかんややってみてもfsck_ufsが見つからないとエラーになってしまう。このキーボード、デフォルトではアンダーバーが押せない(泣)ので、直接実行する術がない。その2CDブートからはあきらめて、HDD起動のシングルユーザモード(Windowsのセーフモードみたいなもんかしら?)でやってみる。シェルを聞かれるのでとりあえず/bin/shでいいや。シェルになったところで同じようにやってみた。/dev/ad0s0aん、できた。できたのはいいけど、不整合とかは無いらしい。ルートファイルシステムだからマウントしているはずだけど・・・まぁ、問題ないならいいか。その3続けて他のパーティーションも同じようにやってみた。すると、ほとんどのパーティーションに不整合が見つかった。修正しても良さそうな感じだが、英語で内容がはっきりわからない(泣)ので、念のため調査してからにしよう。時間切れ気がついたら・・・もうすぐ21時・・・。時間切れになってしまったので、一旦家に帰って調査&対策を練ってから、休み明けの業務開始前になんとかしよう。休み明けゴールデンウィーク中にfsckとそのメッセージについて調べてきた。電源を入れ、HDDからシングルユーザモードで起動する。システムがアクティブにしているデバイスでは使用中の領域がどうしてもあるため、その部分の検査は誤検知するということだった。ハードディスクの全てのパーティーションにfsckを実行してみると、結局「(使っていない領域があるため)ディスクの使用量が食い違っている」というメッセージが出たらしい・・・たぶん(おい)。そんなわけでyで修正。業務開始なんとか業務開始までに再チェックも済ませて、改めて再起動までこぎつけた。その後は特に問題は発生していないようだ。ログは?/varが修正されているので、なにかログファイルにデータ的な損傷が出ているかもしれないと思い、調べてみた。ログファイル自体が壊れているような感じは無かった。最初にfsckでバックグラウンドチェックしている時の状況がシステムログに残っていた!。「どこそこのinodeのファイルサイズがおかしい」とかいうメッセージが大量に残っていた。どのファイルなんだろう?。inodeといえばん?inodeといえばfindコマンドの条件にそんなのなかったか?。マニュアルを調べてみたら、やっぱりあった!。これを使ってどのファイルがダメージを受けたか調べてみる。inode壊れたファイル結局、壊れたらしいファイルは、カーネルパニックを引き起こした自作プログラムが書き出した一時ファイルと、entropy.?ファイル・・・。調べてみたらなんか、いらなそうだな。いうわけで、再起動より古い日付のものはサクッと削除。自作プログラムの一時ファイルも当然サクッと削除。パニックなプログラム例のカーネルパニックを引き起こすプログラムがそのままだった。このファイル自体は通常書き換えしないので、たぶん壊れた一時ファイルにアクセスできなくてパニックを引き起こしたと思うのだが・・・。念のためコンパイルし直した。パニックするかな?恐る恐る自作プログラムで一時ファイルを作る動作をしてみた。・・・・・OK!、カモ〜ン。その後その後は何事も無かったように動いている。なんか「朝、サーバに繋がらなかった」というクレームがあったが適当に涼しい顔で「すんません電源入れるの遅くなりました」みたいな返事をしておいた。いえば見かけたよーな、という感じだったが、調査してみるとなかなか面白い動きを見せてくれそうだ。apache2最新版apache2はスタティックリンクでコンパイルしてあったのと、(現業のほうが忙しく1人で残業中だったので)、どうせならと思い、apacheの最新版2.0.63(当然、当時の最新だが)のソースを拾ってきた。コンパイルスクリプトも手直ししてコンパイル。見ていなかったが小一時間程度でmakeまで終わったようだ。神に祈りつつインストール。startDSOモジュールapache2を起動しようとしたらモジュールが見つからないと蹴られた。httpd.confを試行錯誤して手直しする。使わないつもりだったモジュールが、実はhttpd.confで使っていたということだ。全部DSOでも良かったかな?とりあえずOKhttpd.confの訂正だけで実運用もクリアした。何もトラブルなく動いているようだ。Webサーバのアップデートなんて会社で知っているのは俺ぐらい・・・。PHP5、実機で再チャレンジ番外:仮想サーバにてPHP5リベンジにて仮想サーバでPHP5が動くことを確認したので、実機インストールに再チャレンジしてみようと思う。(ていうかこのインストール記録も時間軸飛びまくってるなぁ・・・(汗))さぁ休日出勤だ今日は休日出勤。・・・他に誰もいない(汗)。これは神様が俺に「サーバを止めるなら今ですよ」と言ってくれているに違いない(笑)。startお、ちゃんと起動してるじゃん。phpinfo()もちゃんと5.2.6になってるね。テスト版プログラムを動かしてみたら・・・表示された。こっちのプログラムは?・・・おや?反応が遅い。結局タイムアウトになってしまった。こっちは・・・文字化け。おいおい、文字化け対策は直ったんじゃなかったのか?。文字化けが発生したので、文字化けしないためのルーチンを調べてみた。すると、以外や以外、mb_convert_variables()関数で止まっちゃう!(=ハングアップというか)。訳の分からないパターンか・・・(泣)。結局、PHP4に戻した。くじけずとりあえず実機だとコンパイルもそんなに時間がかからないし、インストールも見ていられるぐらいの時間で済むので、いろいろなパターンで試してみた。PHP5.2.6→×、PHP5.1.6→×・・・。PHP5系はなんでダメなんだろう?。いうか、仮想サーバでは同じようにやっても問題なかったのになぁ・・・。言えることは、リクエストが発生してからタイムアウトするまでCPUの使用率が100%近くになること、正常にタイムアウトになるよう監視は出来ているということ。調べてみたところ、PHP4とPHP5とで共存できる設定があるということで、実践してみる。おお、とりあえずphpinfo()でそれぞれのバージョンが表示された。Errorが出るようになってしまった。何を変えたらおかしくなったのかもうわからない。headers等が書かれているだけで手がかりは薄い。やめたり/cgi-bin/にScriptAliasしてあるディレクトリを確認してみたりしたが、一向に直らない。ちなみにPHP4は全く問題ない。共存は、直ったPHP5の不具合が原因でPHP4とPHP5の共存がうまくいかないのでは?と疑っていたのだが、念のためapache2の設定を最初の状態に戻してみた。/cgi-bin/php-cgiなんだったんだろう?.htaccessに入れたのが良かったのかと思ったが、行の順番を入れ替えたらおかしくなったので、記述の順番に問題があったようだ。いえ、そんなのマニュアルのどこに書いてあったんだろう?。ちなみに今回の例はかなり適当な部分もあるので丸写しは注意。それでもそれでもやっぱりphpinfo()は動かなかった。コンパイラオプションもいろいろ変えて、終いにはオプション無しでやっても同じだった。それでダメならコンパイラオプションがダメならconfigureオプションかと思い、とりあえずマルチバイト関連とMySQL関連のオプションを外した。MySQL関連を組み込んで・・・。--enable-zend-multibyteだけ足して・・・。--enable-mbregexだけ足して・・・。いうことは、--enable-mbstringが元凶か・・・。待て待てよ?、前にmb_convert_variables()で止まったことがあったな・・・。auto(コメントアウト)php.iniを変更した後、--enable-mbstringも足してコンパイル。動いた・・・orz脳内整理とりあえず頭の中を整理してみよう。PHP5.2.6をインストールをした直後はphpinfo()と、文字化けはしたものの一部のプログラムもなんとか動いていたはず。それ以外のプログラムはタイムアウトしてしまう。310というエラーメッセージがログに記録されていたはず。310はmb_convert_variables()である。0というエラーメッセージも出ていたかもしれない。bison、apache2も含めてコンパイル&インストールした後、モジュール版PHP4とCGI版PHP5との共存を図る。httpd.confの設定変更が原因でCGI版PHP5が動かなくなったのを勘違いし、CGI版PHP5をオプションを変えたりして何度もコンパイル。httpd.confの設定変更が原因だと気づき、CGI版PHP5の共存が復活。0のエラーメッセージが消えない。autoをコメントアウトしただけの状態にしたらphpinfo()が動くようになった。問題が発生していた他のプログラムも、文字化けするものの動くようになった。プログラムの中で$_POST等のスーパーグローバル変数をmb_convert_variables()で変換するとタイムアウトしていたので、mb_convert_encoding()等を使った自前の関数で変換してみたら、文字化けも解消された。mb_convert_variables()が原因かと思いきや、後に再現してみようと思っても現象が発生しなかった・・・なんなんだ?。問題が発生していた他のプログラムではタイムアウト・・・やっぱりなんなんだ?。64bitCPUや64bitOS、ライブラリ等の関係で不安定になっているのか・・・?。それとも特定の文字列を含むクッキーやHTTPクエリが問題なのか・・・?。・・・・・・謎は深まるばかり。再検証いや、どこか勘違いしているかもしれない。最初のphp.iniは次の通り。autoを有効にしてみる。?>をphpinfo.phpというファイルで用意する。phpinfo.php」を実行すると、正常にページの内容が出力される。ブラウザからクエリ無し「phpinfo.phpでリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=123」でリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=abc」でリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=はにほへといろは」でリクエストするとタイムアウトしてサーバエラーが表示される。passに変更してみる。ブラウザからクエリ無し「phpinfo.php」、クエリ付き「phpinfo.php?a=123」、「phpinfo.php?a=abc」でリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=はにほへといろは」でリクエストすると正常にページが出力されるが、$_GET['a']は????????になる(文字化け)。気になったのがEnvironment等のQUERY_STRINGも????????になっている。$_GET);を追加してみる。ブラウザからクエリ無し「phpinfo.php」、クエリ付き「phpinfo.php?a=123」、「phpinfo.php?a=abc」でリクエストすると正常にページが出力される。2とエラー表示される。2行目はmb_convert_variables()。$a);に変更してみる。スクリプトはSJISで、スクリプトの自動変換が有効になっている。ブラウザからクエリ無し「phpinfo.php」、「クエリ付きphpinfo.php?a=123」、「phpinfo.php?a=abc」でリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=はにほへといろは」でリクエストすると正常にページが出力されるが、当然$_GET['a']等は????????になる。'SJIS'));に変更してみる。3とエラー表示される。3行目はmb_convert_variables()。他のクエリ付きの条件でも同じ結果になった。'UTF-8'));に変更してみる。ブラウザからクエリ無し「phpinfo.php」、クエリ付き「phpinfo.php?a=123」、「phpinfo.php?a=abc」でリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=はにほへといろは」でリクエストすると正常にページが出力されるが、当然$_GET['a']等は????????になる。phpinfo.phpのmb_convert_variables()関数を、自前の関数に変更してみる。自前の関数ではmb_convert_encoding()を使用している。ブラウザからクエリ無し「phpinfo.php」、クエリ付き「phpinfo.php?a=123」、「phpinfo.php?a=abc」でリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=はにほへといろは」でリクエストすると正常にページが出力されるが、当然$_GET['a']等は????????になる。'SJIS'));に戻してみる。ブラウザからクエリ無し「phpinfo.php」、クエリ付き「phpinfo.php?a=123」、「phpinfo.php?a=abc」でリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=はにほへといろは」でリクエストすると正常にページが出力されるが、当然$_GET['a']等は????????になる。array(...行をやめて、$_GETを自前の関数で変換するように変更してみる。ブラウザからクエリ無し「phpinfo.php」、クエリ付き「phpinfo.php?a=123」、「phpinfo.php?a=abc」でリクエストすると正常にページが出力される。ブラウザからクエリ付き「phpinfo.php?a=はにほへといろは」でリクエストすると正常にページが出力され、$_GET['a']は「はにほへといろは」と正常に変換されている。他の$_REQUEST['a']やQUERY_STRING等は????????のままである。考えてみたらQUERY_STRING等の????????は、実際はSJISなのにEUC-JPだと思ってSJISに変換出力していたというだけで、変換に失敗して「?」表現になるのは当然のことだ。明日は7月7日、環境省が「夜電気を消せ」と言っている日。うちの会社でもエコ活動を始めた&自分もその推進メンバーに入ってしまっているので、サーバの24時間稼動も見直さなければと思っていた。dailyとかあるのよね。えいっ!って発動時刻を変更してみた。