はじめに
本記事はインフラエンジニア歴6年の低意識へっぽこエンジニアが
エラーと戦った努力跡です。
つよつよエンジニアの皆様からは
そんなん知っとるわ！と言われる気がしてなりませんが
アウトプットが大事だよ！(キラキラ)
という言葉を意識高い友人エンジニアの助言を受け、投稿した次第です。
恥ずかしくなったら消します。
事態
あるWindows Serverへ定期的にFTP接続し、ファイルをPUTする処理がある。
その処理がここ数か月、かなりの高確率でtimeoutを検知するようになった。
何度も接続を試すと成功する事が多く、
ごまかしごまかし運用していた。
条件は同じはずなのに、
何故かうまくいくときといかないときがある。
以前いた運用者は本エラーを「気のせい」で片づけていたが、
その頃よりも明らかに悪化しているため改めて調査をしなおした。
調査したこと
とりあえずFTP接続処理を実行。
やはりうまくいく時といかない時がある事を確認。
PASSIVEで接続する要件のため、
もしかして特定のポートがバッティングとかしているのかも？と思い
コマンドプロンプトから「netstat -nao」を打つとTIME_WAITが死ぬほどでる。
TIME_WAITについて調べていくうちに、以下にたどり着く。
TIME_WAIT：設定次第だが基本数分経てばコネクションはクローズされ、ポート開放される
されてへんやんけ
何かがおかしい
ググった記事を頼りにTIME_WAITがいつクローズされるか設定を確認するも、
特段設定はされておらず、デフォルトのままっぽい事を確認。
なら数分でポート開放されるんちゃうんけ
ググっていた中に、497日問題ってワードを見つける。
以前、OS運用部隊にいたときにサーバを連続稼働させすぎてトラブルとかあったんだよって話を思い出す。
あれ、このサーバいつ再起動したっけ
コマンドプロンプトから「systeminfo」で直近のOS起動日を確認すると数年前・・・！
数年前ってあんた。。。
働かせすぎてごめんね。。。
速攻OS再起動を実施。
netstat打ってもTIME_WAITが表示されなくなった！やった！
FTP接続しまくってもTIME_WAITも増えないし、接続もちゃんとできる。
これにて復旧。
教訓
人もサーバも働かせすぎたら壊れる