/varが60%？

メールで毎日送られてくるサーバーからのログで、
いつからかマウントポイントの/varの使用率が
59%に跳ね上がりました。
/var/log下のログが膨れ上がることも考慮して
varの容量は30GBとってあります。
てことは18GBも使ってる？
web公開領域のドキュメントルートは全て/homeであり
/varは使っていませんので、通常は7GB程度で20%台
前半の使用率となり余裕過ぎのはずですが？
まだ12GBあるのでしばらく放っておきましたが、
いきなり跳ね上がった原因が分からなければ
更に跳ね上がる可能性だってあるわけです。
急に不安になり使用容量を詳しく調べてみました。

/var/logは通常の使用率です。
/var/namedの下にcore.*****（＊は数字）ってのが
いくつかあって、容量は様々ですが、合計すると
10GB超えと結構でかい。。。ｺｲﾂか！

namedはDNSサーバーを構築するデーモンで、設定ファイルは
/var/named下にいろいろ置いてあるように見せかけてますが
chrootを使っているので、実体はもっと階層の深いところに
置いてあり、/var/named下を眺める機会ってそう無いので
気づきませんでした。。。
そこにcoreファイルが出来上がってるのを見るのも
初めてです。

coreファイルってのはプロセスが異常終了した時の
メモリ内容をダンプしたものですから、そのあたりに
新しくチャレンジしたオプションの書式に間違いがあり、
固まってしまい、ニッチもサッチモいかなくなったときに
強制終了させたときのメモリダンプなのでしょう。
core.***の数字はその時のプロセスIDでしょう。
そしてファイルの数は間違えた数でしょう。www

結局試したオプションは拙生の環境下では不向きなようで
不使用と決定したため、core.***は削除の方向で。。。
一応プ稼働中のプロセスを調べて、コアダンプが終了
していることで削除問題なしを確認。
即ぶち消して、ついでにそのうち自動で削除されるであろう
古いログを手動でぶち消しておいたため、現在/varの
使用容量は6GBちょっとで、使用率20%程度となりました。

お勉強不足

ダンプしたcoreファイルの出力場所を指定するコマンドなどは
知っていますが、出力先を/var/named下に指定したり、
あれだけ大量のログを吐くログレベルの設定もしている
設定ファイルの所在などの知識が皆無です。。。
必要になったら探しに行きましょ、では一生知識として
身に付きませんよね。
時間が出来たら調べてみなくてはなりません。

本日のお役立ちコマンド

du /var -h -d * | sort -h

duはディスク使用量。
オプション
-h　単位を見やすいGBやMBにする。
-d * *は数値を入力。その数値の階層分まで計算する。

パイプで連結したコマンド
sortでサイズ順に並べてくれる。　
注意
単にソートするとGBやMBの単位に関係なく
数字飲みの昇降順としてしまうため、オプショの
-hで単位を読み取らせる。（1GBは2MBより大きい）

!du

!を頭に付すと直近に行ったコマンドのオプションなどを
そのまま引き継いで実行してくれます。
意外と知らないショートカット術かな。（笑
ただし直前に行ったコマンドなどは↑でhistoryから
読み込んだほうが早い場合もあるので使い分けます。

拙生がよく使う例

直近のshコマンドが
sh /etc/cron.daily/backup.sh
であったなら、
!sh
で
backup.shが実行されます。

cron.dailyに置いてあるので毎日自動実行されますが
手動で実行したい時はだいたいは!shとやります。
shコマンドはバックアップ以外は多用しないので
コレを使ってショートカットできます。
ちなみに!shで実行してもhistoryには
sh /etc/cron.daily/backup.sh　で記録されます。