原因を突き止めようとしてduコマンドを使ったら･･･
急にルート・ファイルシステムの使用量が増えてしまいました。「df」コマンドで調べると随分と空き領域が減っています。
以前、kern.logとsyslogが膨れあがったことがあったので、「また何か巨大なファイルが作られたのか？」と思い犯人を突き止めようと「du」コマンドでチェックしたところ・・・
dfコマンドの結果 ＞＞ duコマンドの結果
となってしまいました。
「du 合計 合わない」などでgoogle検索して見ると、「削除済みで未解放のファイルがあると、dfでは計上されるが、duでは計上されない」といった旨の情報が見つかりました。早速、それらの情報を参考に「sudo lsof +L1」コマンドを実行してみましたが、それらしきファイルは見つかりません。
急に使用量が増えたときに何をしていた？
急に使用量が増えたとき、自サーバのデータを、別のサーバにバックアップする処理を行っていました。別サーバにSambaで共有フォルダを作り、自サーバからマウントし、自サーバ上でrsyncコマンドを使ってバックアップする処理です。これを深夜にcronで実行しています。そのログを確認してみると毎日実行しているのに・・・
created directory /mnt/hoge/hoge
と、rsyncコマンドが言っています。毎日同じ処理を実行しているのに、今更「created」はおかしい・・・これを見落としていました。つまり
何らかの理由で別サーバの共有フォルダが、自サーバにマウントされていなかった
ことが判りました。ずっと削除済みで未解放のファイルがあると思い込んでいて、原因がわからず焦ってしまっていました。
結局、何が起きていた？
やっと原因が自分なりに整理できました。
- 何らかの理由で、別サーバの共有フォルダが、自サーバにマウントされていなかった
- マウントされていないのに、そこにファイルを保存(rsyncでバックアップ)した
- マウント・ポイントのつもりで用意していたフォルダに、実際にファイルが作られた
- ディスクの使用量が急増したことに気づき、dfコマンドやduコマンドを使って原因を探ろうとした
- 別サーバの共有フォルダを自サーバにマウントするのに、fstabで「x-systemd.automount」を指定していたので、原因を探ろうとしたときにはリモートファイルシステムにアクセスできた(再起動もしたので、そのためか？)
- 2～3.の処理で自サーバに保存されたファイルがduコマンドで計上されない、でもファイルシステム上には存在するのでdfコマンドで計上された
- df >> duの結果になった
実際に、fstabの記述をコメントアウトし別サーバの共有フォルダが自サーバにマウントされないようにして、再起動して、マウント・ポイントを見てみると、あるはずのないフォルダ・ファイルが見つかりました。
これらのフォルダ・ファイルを削除し、fstabの記述を元に戻して再起動し、やっとdfの結果＝duの結果になりました。
教訓
dfコマンドの問題か？、duコマンドの問題か？、もしかしたらrsyncコマンドが原因か？･･･と思い込んでしまい、リモートファイルシステムにアクセスできていなかったことに気づけませんでした。まさか、マウント・ポイントのつもりで作ったフォルダに、ファイルの実体があるなんて･･･
解決のヒントが「ログファイル」に隠されていたので、軽く読み飛ばしてはいけない･･･と改めて思います。
