障害報告 †
2008年 †
- 11/5
◆ORZダウン
対象： FW
発生： Nov 5 23:53:03
復旧： Nov 6 23:42
状態： 状況確認中。
詳しい発生状態と原因は不明。
障害発生時刻に、FW の ORZ 監視スクリプトが
WWW 上の ORZ 障害を検知し、フェイルオーバーを起こした。
WWW の apache のログは、22:53:03 に最後のアクセスが記録されている。
FW の apache のログは、22:53:04 よりアクセス記録が開始。
切り替わりが１秒というのがおかしい。
→監視スクリプトでのエラーは Wget の返り値で障害を判定。
タイムアウトでなく、いきなり切り替わっている。
→返り値のチェックをしていないので状態がわからない。
WWW, FW 両ホストでのログや負荷等を調査するも普段と同じく原因が見当たらない。
CPU, MEM, DISK 等のデバイスの不良やネットワーク障害でもない模様。
外部監視サービスでは Web (port 80, 443) のみの障害として検知されている。
その他の障害として、WWW → FW への NTP sync が切れている。
しかし、この障害との関係は不明（以前からそうなっていた可能性あり）
該当時刻に SHARE を使ったファイル共有を行っていた。
この辺りが原因に関係している可能性もあり。
原因： 不明
対応： 状況確認中
問題： 状態、原因が不明な事。
監視スクリプトで URL チェックの際のタイムアウト時間を明確にする必要あり。
同じく、wget で障害検知した場合の返り値を通知に含める必要あり。
PF ルールを切り替える際、切り替え前に PF の ルールだけでなく、
state もクリアした方が良さそう。
ntp チェックスクリプトの改良(ローカル同期は障害とみなす）
考えられる可能性：
share による TCP セッション過多。
→しかしネットワーク経路が別の為、 share は WWW 自体の動作には影響しない
apache + fast cgi の不具合によるタイムアウト
→暫し暴走する、原因不明の httpd の cpu暴走迷子子プロセスが関係あり？
- 09/24
◆メールゲートウェイダウン
対象： FW
発生： Sep 23 16:33:19 (←amavisd のログにエラーが記録されていた)
復旧： Sep 25 00:05
状態： 復旧
原因： clam-antivirus deamon ハングアップ
clamav ヴァージョンアップによる仕様変更
virus-alert action に指定していた mail コマンドを使ったメッセージ送信がゾンビ化していた。
→ sh -c mail -s "メッセージ"
対応： virus-alert action をコメントアウトし、プロセスリスタート
問題： postfix は生きていた為、外部障害検知システムアラートに乗らなかった（エラーステータスを返していた）
対応策を考慮する必要あり
◎ amavisd ログ
Sep 23 16:33:19 fw amavis[46473]: (46473-13) (!)ClamAV-clamd: timed out, retrying (2)
Sep 23 16:33:35 fw amavis[46473]: (46473-13) (!!)ClamAV-clamd av-scanner FAILED:
run_av error: ask_daemon_internal: Exceeded allowed time at (eval 101) line 308.
Sep 23 16:33:35 fw amavis[46473]: (46473-13) (!!)WARN: all primary virus scanners failed, considering backups
Sep 23 16:33:45 fw amavis[46473]: (46473-13) (!)killing process [48517]
running ClamAV-clamscan (reason: on reading: timed out)
Sep 23 16:33:45 fw amavis[46473]: (46473-13) (!)run_av (ClamAV-clamscan):
collect_results - reading aborted: timed out at /usr/local/sbin/amavisd line 3089.
Sep 23 16:33:45 fw amavis[46473]: (46473-13) (!!)ClamAV-clamscan av-scanner FAILED:
run_av error: run_av: Exceeded allowed time at (eval 101) line 516.
Sep 23 16:33:45 fw amavis[46473]: (46473-13) (!!)TROUBLE in check_mail: virus_scan FAILED:
virus_scan: ALL VIRUS SCANNERS FAILED: ClamAV-clamd av-scanner FAILED: run_av error:
ask_daemon_internal: Exceeded allowed time at (eval 101) line 308.; ClamAV-clamscan av-scanner FAILED:
run_av error: run_av: Exceeded allowed time at (eval 101) line 516.
Sep 23 16:33:45 fw amavis[46473]: (46473-13) (!)PRESERVING EVIDENCE in /var/amavis/tmp/amavis-20080923T150430-46473
◎ mailq メッセージ
(host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=62350-09,
virus_scan FAILED: virus_scan: ALL VIRUS SCANNERS FAILED:
ClamAV-clamd av-scanner FAILED: run_av error: ask_daemon_internal: Exceeded
allowed time at (eval 101) line 308.; ClamAV-clamscan av-scanner FAILED:
run_av error: run_av: Exceeded allowed time at (eval 101) line 516. (in reply to end of DATA command))
- 08/24
◆システムダウン
対象： FW, WWW
発生： 21:30
復旧： 22:24
状態： 復旧
原因： 落雷による停電
対応： xfs_repair をかけてリブート
- 07/28
◆HD 障害（/home)
対象： WWW
発生： 13:57
復旧： 21:30
状態： 復旧
原因： HD 老朽化
対応： xfs_repair をかけてリブート
Jul 28 13:57:40 ns kernel: xfs_inotobp: xfs_imap() returned an error 22 on hda7. Returning error.
Jul 28 13:57:40 ns kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on hda7. Returning error.
Jul 28 13:57:40 ns kernel: xfs_inactive:^Ixfs_ifree() returned an error = 22 on hda7
Jul 28 13:57:40 ns kernel: xfs_force_shutdown(hda7,0x1) called from line 1737 of file fs/xfs/xfs_vnodeops.c. Return address = 0xc01e93a6
- 06/11
◆システムシャットダウン
対象： FW
発生： 16:32
復旧： 20:11
状態： 復旧
原因： 突然の電源断？原因不明。増設したメモリ関連か電源辺り？
対応： ブート
- 05/22
◆システムフリーズ
発生時刻： 23:34:30
復旧時刻： 01:30:20
状態： 復旧
原因： 2ch サーバダウンに伴う orz.cgi の負荷上昇により /home 領域の file system に異常が発生
May 22 23:34:30 ns kernel: Filesystem "hda7": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xc01e6e02
May 22 23:34:30 ns kernel: Pid: 20695, comm: orz.cgi Not tainted 2.6.25 #1
May 22 23:34:30 ns kernel: [<c01e12c9>] xfs_trans_cancel+0x4d/0xd2
May 22 23:34:30 ns kernel: [<c01e6e02>] xfs_create+0x382/0x3f5
May 22 23:34:30 ns kernel: [<c01e6e02>] xfs_create+0x382/0x3f5
May 22 23:34:30 ns kernel: [<c01ef903>] xfs_vn_mknod+0x140/0x22b
May 22 23:34:30 ns kernel: [<c0154dfd>] vfs_create+0x9b/0xdb
May 22 23:34:30 ns kernel: [<c0157017>] open_namei+0x15d/0x50a
May 22 23:34:30 ns kernel: [<c014da28>] do_filp_open+0x1c/0x31
May 22 23:34:30 ns kernel: [<c014da7d>] do_sys_open+0x40/0xb5
May 22 23:34:30 ns kernel: [<c014db36>] sys_open+0x1e/0x23
May 22 23:34:30 ns kernel: [<c0104516>] sysenter_past_esp+0x5f/0x85
May 22 23:34:30 ns kernel: [<c02f0000>] xfrm_state_alloc+0x3b/0x10f
May 22 23:34:30 ns kernel: =======================
May 22 23:34:30 ns kernel: xfs_force_shutdown(hda7,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xc01e12df
May 22 23:34:30 ns kernel: Filesystem "hda7": Corruption of in-memory data detected. Shutting down filesystem: hda7
May 22 23:34:30 ns kernel: Please umount the filesystem, and rectify the problem(s)
問題：各デーモンプロセス自体は生き残っていたので、リモート監視サービスから異常状態と見なされなかった。
対応：OS の強制リブート
ここ数日 iowait 値が高かった事に加え、
以前行った hdparm 周りの設定が今回の障害を引き起こした可能性もある。
unmaskirq = on (ディスク割り込み処理中に他の割り込みのマスクを (ドライバーが)外すことを許可する)
write_cache = on
にしてた辺りが怪しいと推測。
この為、hdparm の設定を以下のように単純なものにし、様子を見る。
# hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 241254720, start = 0
# cat /etc/hdparm
/dev/hda {
mult_sect_io = 16
dma = on
write_cache = off
}
2006年 †
- 11/16
◆mpd セッションエラー
発生時刻： 20:54
復旧時刻： 23:54
状態： 復旧
原因：「これはちょー予測」
電話がかかってくると必ず PPPoE セッションが途切れてしまう。
セッション切れが発生しても mpd で echo パケット送信をリトライするが、
リトライ回数を超えて再セッションが張れないと、リンクダウンを起こして
PPPoE セッション自体を再接続しようとする。
この際、mpd 側ではリセットパケットのようなものを送らずにセッション開始する。
しかしプロバイダーの ppp サーバでは以前のセッションが残っており、
すでに接続されているセッションと同じ認証で再度セッションがくる為、違法なものと見なすぽい。
これが繰り返され mpd がセッション張るのを諦めてしまう。
回避策：mpd の設定調査＆接続状態を監視しつつリブートさせるプログラムの作成
- 10/07
◆apache cgi エラー
発生時刻： 02:09
復旧時刻： 22:53
状態： 復旧
原因：openssl の SA 対応で apache をリビルドした際に、--with-suexec-docroot が誤った値になっていた為、suexec 環境下の cgi が動作しなかった。
対応：--with-suexec-docroot の指定を正しく変更し、再インストール
- 06/24
◆FW ダウン
発生時刻： 07:06:39
復旧時刻： 08:30
状態： 復旧
原因： 不明
対応： 障害発生時刻に原因不明のリブートが発生。リブート後、ディスクエラーになりシステムが正常に機能しなくなる。（PF ハングアップによるネットワーク遮断等）。
FSCK をかけて復旧。
- 05/24
◆全サービス停止
発生時刻： 18:30
復旧時刻： 20:30
状態： 復旧
原因： 雷雨発生
対応： 上記時間帯において一時的にサーバー停止
- 05/23
◆WEB サービス停止
発生時刻： 18:00
復旧時刻： 20:00
状態： 解決
原因：php4.4.2 が mysql-5.0.20 以上に対応していない為に php のインストール時にセグメンテーションフォルトになり、apache を稼動させられない。
対応：mysql のバージョンを元に戻した。
- 04/05
◆NET-PRIV (ユーザ用セグメント）で DHCP が使えない
発生時刻： FW 導入時より
復旧時刻： ???
状態： 解決
原因： ユーザ用セグメントの NIC の故障
対応： NIC の交換
- 04/04
◆全サービス停止
発生時刻： 19:05
復旧時刻： 19:40
状態： 解決
原因：新規 FW 機をネットワークに組み入れた所、Web サーバセグメントの NIC がリンクアップしない。４枚ある NIC と接続するマシンとの組み合わせによって、リンクアップしたりしなかったりする。（FW 以外のマシンと Web サーバを接続するとリンクアップする。）
リンクアップについては、ケーブルの種類（ストレート／クロス）を間違えていた。
しかし、ルータとの通信がパケット落ちする状態であった。
ルータと Intel NIC との相性が悪かったらしい。
対応：ネットワーク内の MTU の値を 1500 で統一した
- 03/26
◆全サービス停止
発生時刻： 4:00 頃
復旧時刻： 6:00 頃
状態：解決
原因：停電。停電自体は５分程度で復旧したが、システムチェックに時間が掛かった。www.tukizakura.org に異常は見受けられなかったが、fw.tukizakura.org の HD のいくつかのセクタがお逝きになった模様。
対応：fsck をかけた。fw.tukizakura.org の HD については、このホストは無くてもサービス自体には影響がない為、今回は交換見送り。
◆外部通信不可
発生時刻： 0:30 頃
復旧時刻： 2:00
状態：解決
原因：FW 機 OS アップデートの為に FW をネットワークから切り離した際に、ルーターの設定に古いスタティックルートの設定を残したままにしてしまった。この為、ルーターと IP 通信が行えずルーターの設定変更が行えなくなり内〜外の通信が全て不可能になってしまった。
具体的には、ルーターが所属するネットワークアドレスに対するパケットを旧 FW に転送する設定を残していたので、ルーターにアクセスした際の返りのパケットが存在しない（切り離した） FW に送られ通信不可能になっていた。
対応：ルーターを完全に初期化し、再設定を行った。
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
