WEBサーバの稼働日が399日目だったが、
javaのアプリケーションの安定動作の為、定期的に再起動を掛けている。
利用者のセッション情報を上手く離さないままで正常に終了しない状態が続くと
応答を繰り返す可能性があるが、利用者への配慮でタイムアウト時間をかなり長めに取っていることにも起因している可能性がある。
正常時は、正しく返す応答が、中途半端にセッションを有したまま、再起動が掛かってしまい、当然セッションがないので、応答が次々と繰り返られれば、
短い時間でスレッドの上限に達し、ヒープ領域の食事を延々を行い、
ヒープ領域を食い尽くし、FULLGCが起こる原因になりかねない。
タイムアウト時間の見直しは課題として、検討を行うとして、
前段が長くなったが、上記の状態に陥り、load averageが7近くまで上昇してしまい、
各アプリケーションが自然に停止してしまった為、止むを得ずWEBサーバ
の再起動を行ったのだが、およそ一年前にコンソールから追加できないディスク領域の拡張依頼をしたのだが、その際、fstabが修正されておらず、今回の症状となったようだ。
system logs, "systemctl reboot" to reboot, "systemctl default" to try again to
boot into default mode.
Give root password for maintenance (or type Control-D to continue):
と表示された・・・。
rootでログインし、
# mount -a でどのマウントが引っかかっているか原因を探る。
/etc/fstab の構成と比較し、 /dev/sd?のドライブレターと齟齬が生じている箇所を
修正する事となる。
複数のドライブに不具合が生じている際は、正しいマウント先を確認しながら
fstabの修正が必要となるので、注意のこと。
尚、不可解な点が一点あり、fstabの先頭に\が記載されていた。
コンソールからの追加では、自動的にfstabが書き換わる仕様だが、
エンジニアが介入する特殊なディスク領域拡張にはおそらく対応していない為、
作業マニュアル等の中に、作業開始時にシステムの破損を防ぐため、
fstabの先頭に\を記載し、上書き保存 のようなルールがあるのではないか？
事実、ドライブの構成を確認しながらfstabを修正する破目に陥ったので、
最も効率的にリスクを回避できるので、上記のルールを策定した人は、
とても頭の良い方だと素直に尊敬できる。
https://www.symmetric.co.jp/blog/archives/65
https://atmarkit.itmedia.co.jp/ait/articles/0711/27/news122_3.html
の記事が大変参考となった。感謝いたします。
