身近であった怖い話（Linux環境）#1
2019 年 4 月 8 日 by hiro-kお疲れ様です。
身近であった怖い話（Linux環境）の情報を展開していこうと思います。
今回は皆さんもよく利用する（と思われる）viewコマンドであった怖い話です。
ある開発者がアラーム調査のため、ログを参照しようとviewコマンドを利用して
ログファイルを開いたそうです。
コマンド実行後、しばらく応答がなく、どうしたのかと思った時、
マシンリブートが走りました。
この調査作業を本番環境で実施していたということもあり
マシンリブートによるアラーム通知が大量に上がり、
さらに専用マシンではなく、他のシステムでも利用している
共用マシンであったため、被害が広がりました。
さて、なぜマシンリブートが発生したのか・・・ですが、
開こうとしたログファイルが１日１ファイル等の分割されたファイルではなく
１ファイルに出力し続けるログファイルらしく
ファイルサイズが３ＧＢｙｔｅを超えていたそうです。
そのため、viewコマンドで対象マシンのメモリを食いつぶし、
何もできない状態となったことで、生きていないマシンと監視で判断され
マシンリブートが行われました。
これはviewコマンドだけではなく、viコマンドでも同様のことが起こります。
この問題について、大きく以下の点があげられました。
１．なぜログファイルが日付・時間単位等のファイルではないのか。
２．なぜログファイルがローテートされていないのか。
３．なぜ本番環境でvi/viewコマンドといったファイルを更新できるコマンドを
利用したのか。
それぞれの対応・対処として決まった内容です。
※皆さんとは環境が異なると思われるため、以下については
あくまで参考としてみてください。
１について：プログラム改修を行うということで対応
※当初この対処はなく、２のローテートで
対処しようとしていたようですが、
問題が発生したためにプログラム改修となりました。
問題について詳細なことは聞いていないので判りませんが、
・常駐プロセスである
・１ファイルに出力し続ける
ということから、
ファイルをopenしたままのプロセスだったのではないかと
思われます。
２について：既に対象マシン上に存在するローテートツールで対応
３について：本番環境でvi/viewコマンドを利用するのが問題であるため、
利用できないようaliasでlessコマンドに置き換えで対応
皆さんもvi/viewコマンドを常日頃から利用していると思います。
もし、本番環境などで利用するとき、このことを少しでも思い出して
参照するファイルのサイズを確認したり、設計時点でファイルサイズが
肥大化しないように設計してもらえるとうれしいです。
※ちなみにファイルサイズを気にするのはvi/viewコマンドだけではありません。
他にもあるかもしれませんが、sortコマンドでも気にする必要があります。
こちらは特にオプション指定しなければsortの一時領域として
/tmpが利用されるのですが、ファイルサイズが大きなものだと
/tmpの使用率が100%になることがあります。
注意してください。
タグ: Linux vi view 注意
