■とある障害の話

これはLAN内で使っているだけの、しょっぱいエントリクラスのサーバ1台障害の話だ、価値のある話ではない。

とある国内最大級の某グループウェア Office(パッケージ版)を使っている。

この某グループウェアは、従業員の「その日のタイムカードの一覧」を見ることができない。

CSVでエクスポートすれば可能だが、営業マンは勤怠をガラケーのメールで報告する運用であるため、

スマホ支給しろ 一覧＋タイムカード修正画面へのURLリンク付きで

総務課の人にスクレイピングしてあげていた。

↓大雑把にこんな感じ

#!/usr/bin/env perl
use MY::Cybozu;

my $cb = MY::Cybozu->new;
$result = $cb->get_timecard( sprintf("%d.%.d%", $year, $month, $day) );

&send_mail( $result );

数年来やってきていたのだが、突然このスクレイピングでデータが取れなくなった。

僅かにPerlを書けるだけで、他の言語は将棋を指すようにしか書けない低能である、

まず自分のスクリプトを疑った。

ちょうど20日の月替りのタイミングだったので、スクリプトのミスでズレたのか？

或いは、タイムカードのHTMLはtable構造で「trの何番目が何日目」という原始的な処理の方でズレたか？

しかし、日付に関係なくダメになったのである。

ほぼほぼデータを取れないのだが、たまに正常に取れたりもする。なんだこりゃ。

$mech->statusの結果はいつも200である。

print $mech->contentの結果は、HTMLが途中で途切れていた。

スクレイプ対象の前で途切れたので、値を取得できなくなっていたのだ。

同じ場所で途切れる事が多いが、若干の増減はあった。

手元のWindowsマシンに移植したところ、まったく問題ない。

どうやらスクリプトを動かしているLinux側の問題と思われる。

が、Webアクセスしてコンテンツが途中で途切れるって何だ？

どういう現象なのか？

そこまでの知識も経験もなければ、調べ方も分からない。

分からないなりに、とりあえずtcpdumpしてみた。

3WAYハンドシェイクはよく知られた話だが、正常な通信では、サーバから送られてきたパケットに対して

こちらは「ここまでのパケット受け取った」とACKを返し、最終的にサーバからのFINでこちらがRST返すのが見て取れた。

この異常をきたしたスクリプトでは、ある程度を過ぎると、こちらがACKを返す前にサーバからどんどんパケットが送られ、

突如としてこちらがRSTを連打し、切断してしまっていた。

なるほど、ステータスは200だけど、コンテンツは途切れているのだな。

悪いのは、いよいよこちら側である事は間違いない。

でもスクリプトじゃなくて、ネットワーク制御しているOSが悪いっぽい？

となると深刻である。自動車に乗れても内燃機関の構造など把握していないのだ。

唯一、tcp_abort_on_overflowでそれっぽい挙動をしそうだと分かったが、この機能は使われていない。

詰まった。

お手上げだ。

でも分かった。

端末からNASのディレクトリへ、TAB補完しようとすると突如フリーズしたのだ。

他のスクレイピングは正常に動作してる。

httpdも正常に動作してる。

MySQLも正常に動作してる。

某グループウェアへのスクレイピングとNASへのTAB補完だけが動かない。

故障だ。

単にマシンの故障だ。こういうヘンテコな挙動をするのは。

1.3万円で買って7年目の某ProLiantサーバだから、寿命なのだろう。

オチはないけど、最初から故障を強く疑っても良かったではないのか、と自省する。

そのマシンでのみ失敗し、しかも失敗したりしなかったり(比にして7:3程度)、結果も毎回変わっていたのだから。

うーん無能。

Permalink | 記事への反応(0) | 14:52

ツイートシェア