前置き
先日、自社で納品したWEBアプリを使用しているクライアントから
『今朝いきなりログインができなくなり、アプリケーションが表示できない。早急に原因を調査し解決して欲しい。』と連絡があり、対処する機会があった。
推測してみる
いったんrebootコマンドでサーバーを再起動してみるが動作は解消せず。
色々な原因が考えられたがその時までアプリケーションは2年近く問題なく動作していたため、格納されているオンプレミスサーバー内ディスクのメモリが何らかの原因で容量ギリギリまで使用されていたのではないかと推測し、調査した。
調査した
まずteratermでサーバーに接続後、以下のdf -hでサーバー内全体のディスクの容量を確認した。
df -h
画像はないが、何故か/varディレクトリ以下が88%使用となっており、仮説が正しそうと思い始める。次にディレクトリを移動しながらdu -sh/*でディレクトリごとの容量を確認していく。
du -sh/*
すると/var/spool/mail/rootディレクトリで80%以上使用しており、このディレクトリが肥大化したことでサーバーが動作しなくなったと突き止める。
調べた結果cronがrootにログを送っているファイルであった。
直下のログファイルを確認すると毎日cronで動かしているシェルファイルでvar_dumpして値の確認をしていたphpファイルがログに出力したまま放置されていた。
その結果、繰り返しサーバーの容量を圧迫していきある日動かなくなったということだった。
対処した
まず、var/spool/mail/root内のログを空にするため、以下のコマンドを実行。
cat /dev/null > /var/spool/mail/root
その結果、該当ディレクトリが空になったことを確認した。
その後、原因となっていたログを出力していたファイル内のvar_dumpを全てコメントアウトし、再度ログを空にした。
また、rootにcron宛のメールが送られることも原因であったので/etc/crontabを開いて、以下の内容に変更した。
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
- MAILTO="root"
+ MAILT0=""
// ... 略
対処した結果アプリケーションが動き出し、クライアントの業務も動き出した。
胸を撫で下ろす。
感想
安直だがログを出したまま、放置しないことはやはり大事。どこで動作不良の原因になるかわかったものではない。本番で問題が起こると焦るが原因を推測しつつ段階を追って対処することが緊急時ほど重要であることを再確認した。
参考URL
近況
最近CI/CDをやりたいと思い、以下の書籍を購入しGithubActionsについて学習している。
サンプルコードも付いていて動作が分かりやすい。時間をかけてでも理解していきたい。
後はSAAを年内には取りたいなと思っている。
