どうしてもサーバの反応がなくなってしまいます（今日もほぼ一日オチていた）。
マシン自体がオチている訳ではなく、ディスクへのI/Oで処理がいっぱいいっぱいになっているっぽいんですよねー。
いっぱいいっぱいになり始めのうちはsshで（やっこらせと）接続できるのですが、結局のところ何がディスクにアクセスしているのかは分からずじまい。
ただ、httpsdをリスタートさせるとサーバへの（すべてのプロトコルでの）アクセスが回復することから、とりあえず定期的にhttpsdを再起動させることで対処してみることにしました。
・・・こんなことでいいのかな・・・。
定期的に何かを処理させるための仕組みはcronですが、実は今まで使ったことがありませんでした。そこでまずはcronについて調べることに。
cronを実行するには、cronの設定ファイル（/etc/cron*）をいじるか、crontabコマンドを使うようです。一般的にはcrontabコマンドを使って、該当する処理を「/var/spool/cron/ユーザ」に記入して定期的に実行させる方法を用いるようなので、ここでもcrontabコマンドを使うことにしました。
ちなみに定期的に実行させるのはhttpsdのリスタートですから、おそらくcronによる処理の実行もroot権限で行われなければならないと思うので、rootで作業を行います。
まずはrootでログインし、crontabコマンドを叩きます。
$ su –
# crontab -e
-eオプションはcronを対話的に記述できます。ってゆーか、エディタ（vi）が立ち上がるので、それに記入していくことになります。viを閉じれば自動的にcronとして保存されます。
viのモードになったら、ここにcrontabの中身を書き込みますが、記述にはルールがあり、
分 時 日 月 曜日 ＜コマンド＞
で記述します。各要素の間は空白で区切ります。詳細はこちらに詳しいのでそちらを見ていただくとして、紹介されている事例で手っ取り早く確認するとこんな感じ。
00 14 * * * /usr/bin/cmd // 毎日14:00に実行
* * * * * /usr/bin/cmd // 毎分実行
15,30 06 * * 2 /usr/bin/cmd // 毎週火曜日の6:15と6:30に実行
05 23 * 3-5 4 /usr/bin/cmd // 3~5月の毎週木曜日23:05に実行
00 14だから14:00の意味になり、*（アスタリスク）は「すべて」を意味するので、一番上の例ならすべての日にち・月・曜日の14:00に実行、となるため、毎日14:00に実行すると解釈される訳ですね。
スパンの指定方法などは細かく色々あるみたいですが、さしあたってこれがわかればOKでしょう。
例えば僕の例ならば、毎日午前0:00にhttpsdをリスタートさせようと思っているとして、その書き方はこうなるわけです。
0 0 * * * /etc/init.d/httpsd restart
これを記述したらviモードを保存して終了すればcronに登録されます。登録された内容は/var/spool/cron/root（僕はこれをrootで実行させなければならないから）に保存されます。
ちなみに/var/spool/cron/rootはディレクトリではなく「ファイル」です。
ファイルですから、lessして中身を確認すれば、先ほどviモードで記述したそれがそのまま出てきます。つまりviで編集して/var/spool/cronの中にユーザ名で保存している感覚ですね。
試しに実際にcorntabを使う2～3分後にcronでhttpsdをリスタートするように記述・保存して実践してみました。
しかしhttpsdがリスタートしているかどうかなんて目で見て確認できる訳ではありません。
そこでcronのログを確認してみます。cronのログは/var/log/cronにあるので、lessやtailなどを使って確認してみると。
# less /var/log/cron | grep httpsd
Jul 16 19:05:01 boota crond[2808]: (root) CMD (/etc/init.d/httpsd restart)
こんな風に、ちゃんと実行されていることが分かりました。
というわけで、この書式でcronにhttpsdをリスタートさせるよう命令できます。とりあえずそんな頻繁にhttpsdを再起動させるわけにもいかないでしょうから、とりあえず一番アクセスの少ない明け方の時間帯にhttpsdを毎日リスタートさせて様子をみてみる事にします。
対症療法的だけど、これでひとまずの解決を見るといいな・・・。
