- PR -

ログファイルを削除するとsyslog.confを再起動するまでログファイルができない

1|2 次のページへ»
投稿者投稿内容
koara
ベテラン
会議室デビュー日: 2005/09/16
投稿数: 96
投稿日時: 2005-09-26 18:32
RH ES3
Postgres SQL 7.4.5
という環境で

postgres.conf
のsyslog_facilityを書き換え'LOCAL2'として
/etc/syslog.confにLOCAL2.* /var/log/postgres/postgres.logとしました。

syslogd を再起動するとpostgres.logができログが書き込まれました。

週に一度にログを圧縮するためcrontabに
以下logclean.shを実行させたのですがうまくいきません。

rm postgres4.gz
cp postgres3.gz postgres4.gz
cp postgres2.gz postgres3.gz
cp postgres1.gz postgres2.gz
gzip postgres.log
mv postgres.log.gz postgres1.gz

勝手にpostgres.logが出来ると思っていたのですができないため
postgres.logというファイルを作ったのですがやはり書き込まれません。

そこでもう一度syslogdを再起動したところpostgres.logができログが書き込まれました。

シェルスクリプト内にsyslogdを再起動するよう記述しなければいけないものなのでしょうか？


[ メッセージ編集済み 編集者: koara 編集日時 2005-09-26 18:35 ]
angel
ぬし
会議室デビュー日: 2005/03/17
投稿数: 711
投稿日時: 2005-09-26 18:55
こんにちは。
引用:
勝手にpostgres.logが出来ると思っていたのですができないため
postgres.logというファイルを作ったのですがやはり書き込まれません。

そこでもう一度syslogdを再起動したところpostgres.logができログが書き込まれました。

シェルスクリプト内にsyslogdを再起動するよう記述しなければいけないものなのでしょうか？

はい。当にその通りです。

この点に関しては、RedHat系 Linux であれば、logrotate という仕組みで実現されています。
一度、/etc/logrotate.d/ 内の各設定ファイルをご覧になると良いかと思います。
※ 丁度、標準の syslog のローテート設定が、/etc/logrotate.d/syslog という設定で入っています。
man logrotate もご一緒にどうぞ。

なお、logrotate は、cron で自動的に動くよう設定されているはずです。
/etc/crontab と、各種 /etc/cron.*/ 配下をご参照ください。

以上、ご参考まで。
※ ところで、このお話は DB ではなくて Linuxマターですよね?

[ メッセージ編集済み 編集者: angel 編集日時 2005-09-26 18:57 ]
Mattun
ぬし
会議室デビュー日: 2004/08/10
投稿数: 1391
投稿日時: 2005-09-26 19:10
先越された＿|￣|○

引用:

週に一度にログを圧縮するため

単純にログを圧縮しながらローテートしたいだけであれば、
/etc/logrotate.dに、下記のようなpgsqlというファイルを作成すれば良さそうです。
# 脳内で書いてるコードなんで、要検証or突っ込み歓迎

コード:
/var/log/postgres/postgres.log {
    weekly
    rotate 5
    compress
}


最低限のオプションしか書いてないので、あとは必要に応じて追記してください。
その辺は /etc/logrotate.d 内にあるほかのファイルを参考にするなり、
man logrotateを参考にしてください。
koara
ベテラン
会議室デビュー日: 2005/09/16
投稿数: 96
投稿日時: 2005-09-27 09:03
angel様、Mattun様
アドバイスありがとうございます。

amgel様
loglotateですか、linuxはほんとに実用的なものが実装されていますね。
あったらいいなというものは、まず探してみようと思いました。

結局、昨晩以下のスクリプトで完成したのですが、loglotateに変更したいと思います＿|￣|○
cp postgres.log postgres
cp /dev/null postgres.log
rm postgres4.gz
cp postgres3.gz postgres4.gz
cp postgres2.gz postgres3.gz
cp postgres1.gz postgres2.gz
gzip postgres
mv postgres.gz postgres1.gz

>※ ところで、このお話は DB ではなくて Linuxマスターですよね?
言われてみればその通りでした、気を付けます。

Mattun様
>先越された＿|￣|○
同じだけ感謝してます！お気を落とされませんように。
くじけた感の良く出た絵文字使わせて頂きました（ｗ
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-09-27 13:17
もう片付いてるようですが...
引用:

koaraさんの書き込み (2005-09-27 09:03) より:
cp postgres.log postgres
cp /dev/null postgres.log
rm postgres4.gz
cp postgres3.gz postgres4.gz
cp postgres2.gz postgres3.gz
cp postgres1.gz postgres2.gz
gzip postgres
mv postgres.gz postgres1.gz

一般的には、あまりよろしくないです。
シェルスクリプトでやるなら...
mv postgres.log postgres1
rm postgres4.gz
mv postgres3.gz postgres4.gz
mv postgres2.gz postgres3.gz
mv postgres1.gz postgres2.gz
kill -HUP `cat /var/run/syslogd.pid`
gzip postgres1
という感じで。

ポイントは
1. 現在、ログを書き込んでいる最中のファイルをmvする。
　　ここで、mvした後でも同じファイルシステム上にあるようにする
　　（別のパーティションに行かないようにする）ことが重要
2. ログを書いているプロセスを再起動する。
3. 1でmvしたログを、最終的な保存先に移す。
　　その際に、必要なら圧縮を施す
です。1と2の間に生じたログ書き込みは、1でmvしたファイルに
追記されます。
koara
ベテラン
会議室デビュー日: 2005/09/16
投稿数: 96
投稿日時: 2005-09-27 19:24
ぽんす様、
親切にして頂いて嬉しいです。
ありがとうございます。

実は最初、どうしてこうした方が良いのか分かりませんでしが、
よく見ると私のと違って理に適っていて、
こういうのを自信を持って書きたいと思いました。

kill -HUP `cat /var/run/syslogd.pid`
によってうまくpostgres1からpostgres.logに出力先が変わっているんですね。

引用:

一般的には、あまりよろしくないです。
シェルスクリプトでやるなら...
mv postgres.log postgres1
rm postgres4.gz
mv postgres3.gz postgres4.gz
mv postgres2.gz postgres3.gz
mv postgres1.gz postgres2.gz
kill -HUP `cat /var/run/syslogd.pid`
gzip postgres1
という感じで。


私の方は
cp postgres.log postgres
とした時点からログが失われてしまう上
cp /dev/null postgres.logとして
書いている最中のファイルを消していますね。

勉強になりました、ありがとうございます。
angel
ぬし
会議室デビュー日: 2005/03/17
投稿数: 711
投稿日時: 2005-09-28 06:51
おはようございます。
引用:
私の方は
cp postgres.log postgres
とした時点からログが失われてしまう上
cp /dev/null postgres.logとして
書いている最中のファイルを消していますね。

今回は確かに、ぽんすさんの提示された kill -HUP の方法がベターですが、koaraさんの挙げられたスクリプトも、状況によっては十分ありだと思います。

ログローテート機能を持たないアプリケーションで、ログローテートを行う場合、以下の分類になると考えていまして、可能であれば 1 がベスト、そうでないなら 2, 3 の方法になると思います。

0. ログ rename
　rename しただけでは、アプリケーションがログファイルを閉じない限り、rename した先に延々とログを書き込むので、動作し続けるアプリケーションのログローテートとしては不完全です。
前回紹介した logrotate の基本はこちらなので、必要に応じて設定で補強します。

1. ログ rename + アプリケーション reload
　今回ぽんすさんの提示された方法です。
syslog なら HUP のシグナルで、設定を再読み込みすると同時にログファイルを開き直すため、ローテートが実現できます。
※標準の /etc/logrotate.d/syslog でも postrotate で kill -HUP を指定していますね。
※類似例として、Apacheであれば、USR1 や HUP シグナルが使用できます。

2. ログ rename + アプリケーション restart
　1 の方法が取れない場合、代わりにアプリケーションを停止してから再起動することで、ローテートが実現できます。
ただし、停止時の僅かなダウンタイムが難です。

3. ログ copy & truncate
　koaraさんのスクリプトの方式です。( /dev/null のコピーが truncate に相当します )
2. と異なり、アプリケーションを停止せずにローテートができます。
ただし、copy と truncate の間に少しタイムラグが発生するため、その時発生したログの内容が、copy されないまま失われてしまう可能性もあります。
logrotate では、copytruncate という設定で使用できます。

以上、ご参考まで。

[ メッセージ編集済み 編集者: angel 編集日時 2005-09-28 06:52 ]
koara
ベテラン
会議室デビュー日: 2005/09/16
投稿数: 96
投稿日時: 2005-09-28 12:42
angel様　おはようございます。

copytruncateですか、また勉強になりました。
ありがとうございます。

よく見ると
kill -HUP `cat /var/run/syslogd.pid`
が再度上がってくる間のログも欠ける可能性あるんですね。

まず、深夜などは処理がたくさん走ってるので
影響の少ない時間を探したいと思います。


[ メッセージ編集済み 編集者: koara 編集日時 2005-09-28 12:43 ]

[ メッセージ編集済み 編集者: koara 編集日時 2005-09-28 12:44 ]
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）