#freeze
*障害報告 [#p11c822f]

**2008年 [#d911a905]

#br
-11/5~
◆ORZダウン~
対象: FW~
発生: Nov 5 23:53:03~
復旧: Nov 6 23:42~
状態: 状況確認中。
#br
詳しい発生状態と原因は不明。
障害発生時刻に、FW の ORZ 監視スクリプトが~
WWW 上の ORZ 障害を検知し、フェイルオーバーを起こした。~
WWW の apache のログは、22:53:03 に最後のアクセスが記録されている。~
FW の apache のログは、22:53:04 よりアクセス記録が開始。~
切り替わりが1秒というのがおかしい。~
→監視スクリプトでのエラーは Wget の返り値で障害を判定。~
タイムアウトでなく、いきなり切り替わっている。~
→返り値のチェックをしていないので状態がわからない。~
~
WWW, FW 両ホストでのログや負荷等を調査するも普段と同じく原因が見当たらない。~
CPU, MEM, DISK 等のデバイスの不良やネットワーク障害でもない模様。~
外部監視サービスでは Web (port 80, 443) のみの障害として検知されている。~
その他の障害として、WWW → FW への NTP sync が切れている。~
しかし、この障害との関係は不明(以前からそうなっていた可能性あり)~
~
該当時刻に SHARE を使ったファイル共有を行っていた。~
この辺りが原因に関係している可能性もあり。~
#br
原因: 不明~
~
対応: 状況確認中~
問題: 状態、原因が不明な事。~
    監視スクリプトで URL チェックの際のタイムアウト時間を明確にする必要あり。~
    同じく、wget で障害検知した場合の返り値を通知に含める必要あり。~
    PF ルールを切り替える際、切り替え前に PF の ルールだけでなく、~
    state もクリアした方が良さそう。~
    ntp チェックスクリプトの改良(ローカル同期は障害とみなす)~
~
考えられる可能性:
share による TCP セッション過多。~
→しかしネットワーク経路が別の為、 share は WWW 自体の動作には影響しない~
apache + fast cgi の不具合によるタイムアウト~
→暫し暴走する、原因不明の httpd の cpu暴走迷子子プロセスが関係あり?~



#br
#br
-09/24~
◆メールゲートウェイダウン~
対象: FW~
発生: Sep 23 16:33:19 (←amavisd のログにエラーが記録されていた)~
復旧: Sep 25 00:05~
状態: 復旧
#br
原因: 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))
~


#br
-08/24~
◆システムダウン~
対象: FW, WWW~
発生: 21:30~
復旧: 22:24~
状態: 復旧
#br
原因: 落雷による停電~
対応: xfs_repair をかけてリブート


#br
-07/28~
◆HD 障害(/home)~
対象: WWW~
発生: 13:57~
復旧: 21:30~
状態: 復旧
#br
原因: 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



#br
-06/11~
◆システムシャットダウン~
対象: FW~
発生: 16:32~
復旧: 20:11~
状態: 復旧
#br
原因: 突然の電源断?原因不明。増設したメモリ関連か電源辺り?~
対応: ブート

#br
-06/11~
◆システムシャットダウン~
発生時刻: 19:20~
復旧時刻: 19:39~
状態: 復旧
#br
原因: gettext 祭りのアップデートの際、/usr/ports/UPDATE の記載通りに、~
  # portupgrade -rf gettext
  # portmaster -r gettext\*
を行ったのだが、portmaster の最中に突然のシステムダウン(電源断)。~
原因は不明。~
対応: ブート


~
-05/22~
◆システムフリーズ~
発生時刻: 23:34:30~
復旧時刻: 01:30:20~
状態: 復旧
#br
原因: 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
 }

~
-05/19~
◆システムフリーズ~
発生時刻: 01:17~
復旧時刻: 01:23~
状態: 復旧
#br
原因:データバックアップ用ディスクをバックアップ時以外スリープ状態~
にするテストを行っていた際にシステムが固まった。~
 hdparm を使って active ⇔ stanby のテストでフリーズ
 # hdparm -Y /dev/hdb
 # mount -t xfs /dev/hdb1 /mnt
 # hdparm -C /dev/hdb
 の繰り返し
対応:OS の強制リブート~


~
**2006年 [#f90fa955]
-11/16~
◆mpd セッションエラー~
発生時刻: 20:54~
復旧時刻: 23:54~
状態: 復旧
#br
原因:「これはちょー予測」~
電話がかかってくると必ず PPPoE セッションが途切れてしまう。~
セッション切れが発生しても mpd で echo パケット送信をリトライするが、~
リトライ回数を超えて再セッションが張れないと、リンクダウンを起こして~
PPPoE セッション自体を再接続しようとする。~
この際、mpd 側ではリセットパケットのようなものを送らずにセッション開始する。~
しかしプロバイダーの ppp サーバでは以前のセッションが残っており、~
すでに接続されているセッションと同じ認証で再度セッションがくる為、違法なものと見なすぽい。~
これが繰り返され mpd がセッション張るのを諦めてしまう。~
#br
回避策:mpd の設定調査&接続状態を監視しつつリブートさせるプログラムの作成


#br
-10/07~
◆apache cgi エラー~
発生時刻: 02:09~
復旧時刻: 22:53~
状態: 復旧
#br
原因:openssl の SA 対応で apache をリビルドした際に、--with-suexec-docroot が誤った値になっていた為、suexec 環境下の cgi が動作しなかった。~
対応:--with-suexec-docroot の指定を正しく変更し、再インストール~

#br
-06/24~
◆FW ダウン~
発生時刻: 07:06:39~
復旧時刻: 08:30~
状態: 復旧
#br
原因: 不明~
対応: 障害発生時刻に原因不明のリブートが発生。リブート後、ディスクエラーになりシステムが正常に機能しなくなる。(PF ハングアップによるネットワーク遮断等)。~
FSCK をかけて復旧。

#br
-05/24~
◆全サービス停止~
発生時刻: 18:30~
復旧時刻: 20:30~
状態: 復旧
#br
原因: 雷雨発生
対応: 上記時間帯において一時的にサーバー停止

#br
-05/23~
◆WEB サービス停止~
発生時刻: 18:00~
復旧時刻: 20:00~
状態: 解決
#br
原因:php4.4.2 が mysql-5.0.20 以上に対応していない為に php のインストール時にセグメンテーションフォルトになり、apache を稼動させられない。~
対応:mysql のバージョンを元に戻した。

#br
-04/05~
◆NET-PRIV (ユーザ用セグメント)で DHCP が使えない~
発生時刻: FW 導入時より~
復旧時刻: ???~
状態: 解決~
#br
原因: ユーザ用セグメントの NIC の故障
#br
対応: NIC の交換

#br
-04/04~
◆全サービス停止~
発生時刻: 19:05~
復旧時刻: 19:40~
状態: 解決
#br
原因:新規 FW 機をネットワークに組み入れた所、Web サーバセグメントの NIC がリンクアップしない。4枚ある NIC と接続するマシンとの組み合わせによって、リンクアップしたりしなかったりする。(FW 以外のマシンと Web サーバを接続するとリンクアップする。)~
~
リンクアップについては、ケーブルの種類(ストレート/クロス)を間違えていた。
しかし、ルータとの通信がパケット落ちする状態であった。~
ルータと Intel NIC との相性が悪かったらしい。
#br
対応:ネットワーク内の MTU の値を 1500 で統一した~

#br
-03/26~
◆全サービス停止~
発生時刻: 4:00 頃~
復旧時刻: 6:00 頃~
状態:解決
#br
原因:停電。停電自体は5分程度で復旧したが、システムチェックに時間が掛かった。www.tukizakura.org に異常は見受けられなかったが、fw.tukizakura.org の HD のいくつかのセクタがお逝きになった模様。
#br
対応:fsck をかけた。fw.tukizakura.org の HD については、このホストは無くてもサービス自体には影響がない為、今回は交換見送り。
~
#br
◆外部通信不可~
発生時刻: 0:30 頃~
復旧時刻: 2:00~
状態:解決
#br
原因:FW 機 OS アップデートの為に FW をネットワークから切り離した際に、ルーターの設定に古いスタティックルートの設定を残したままにしてしまった。この為、ルーターと IP 通信が行えずルーターの設定変更が行えなくなり内〜外の通信が全て不可能になってしまった。~
具体的には、ルーターが所属するネットワークアドレスに対するパケットを旧 FW に転送する設定を残していたので、ルーターにアクセスした際の返りのパケットが存在しない(切り離した) FW に送られ通信不可能になっていた。
#br
対応:ルーターを完全に初期化し、再設定を行った。

#br

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS