web-dev-qa-db-ja.com

Logrotate成功、元のファイルは元のサイズに戻る

ログファイルがローテーションされて元のサイズに戻る前に、logrotateで問題が発生したことはありますか？これが私の発見です：

Logrotate Script：

/var/log/mylogfile.log {
ローテート7 
毎日
圧縮
 olddir /log_archives
 missingok 
 notifempty 
 copytruncate 
}

Logrotateの詳細出力：

 /var/log/mylogfile.logを/log_archives/mylogfile.log.1にコピーしています
/var/log/mylogfile.logを切り捨てています
ログを圧縮しています：/ bin/gzip 
古いログの削除/log_archives/mylogfile.log.8.gz

切り捨てが発生した後のログファイル

 [root @ server〜]＃ls -lh /var/log/mylogfile.log
-rw-rw-r-- 1 part1 part1 0 Jan 11 17:32/var/log/mylogfile.log

文字通り数秒後：

 [root @ server〜]＃ls -lh /var/log/mylogfile.log
-rw-rw-r-- 1 part1 part1 3.5G Jan 11 17:32/var/log /mylogfile.log

RHELバージョン：

 [root @ server〜]＃cat/etc/redhat-release 
 Red Hat Enterprise Linux ES release 4（Nahant Update 4）

Logrotateバージョン：

 [root @ DAA21529WWW370〜]＃rpm -qa | grep logrotate 
 logrotate-3.7.1-10.RHEL4

いくつかのメモ：

  • サービスをその場で再起動できないため、copytruncateを使用しています
  • olddirディレクトリには、毎晩のログファイルが含まれているため、ログは毎晩ローテーションしています。
linuxredhatlog-fileslogrotate
11
drewrockshard

これはおそらく、ファイルを切り捨てた場合でも、ファイルへの書き込みプロセスは、最後にあったオフセットのいずれかで書き込みを続行するためです。つまり、logrotateはファイルを切り捨て、サイズはゼロであり、プロセスは再度ファイルに書き込み、中断されたオフセットで続行し、切り捨てたポイントまでのNULLバイトのファイルに加えて、新しいログに書き込まれたエントリ。

od -cは切り捨て+急激な増加の後、次の行に沿って出力を生成します。

0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
33255657600  \0   C   K   B   -   s   e   r   v   e   r       [   h   t   t
33255657620 <more log output>

これは、オフセット0から33255657600までの範囲で、ファイルはnullバイトといくつかの読みやすいデータで構成されています。この状態になるには、実際にそれらすべてのnullバイトを書き込むのにかかる時間と同じ時間はかかりません。 ext {2,3,4}ファイルシステムはスパースファイルと呼ばれるものをサポートしているため、何も含まれていないファイルの領域をシークすると、その領域はnullバイトが含まれていると見なされ、領域を占有しません。ディスク上。これらのnullバイトは実際には書き込まれず、そこにあると想定されているため、0〜3.5 GBになるまでにかかる時間はそれほど長くありません。 （dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1のようなことを行うことで、所要時間をテストできます。これにより、数ミリ秒で3GBを超えるファイルが生成されます）。

ログファイルが切り捨てられて再び急激に増加した後、ログファイルでls -lsを実行すると、行の先頭に、実際のサイズ（ディスク上で占有されているブロック数）を表す数値が報告されます。おそらくls -lによって報告されたサイズよりも桁違いに小さいです。

18
Kjetil Joergensen

私は非常に Kjetilがヒットしたと確信しています。ドリュー、彼の説明にはまだ納得していないかもしれませんが、彼の言ったことを注意深く読んでください。

それを受け入れる場合、修正は、ログがローテーションされたときにアプリケーションを停止して再起動するか、Apacheの「rotatelogs」などのツールを使用して、ログ出力をパイプ経由でツールにフィードし、ツールが処理するログファイルを時々ローテーションします。たとえば、私のApacheインスタンスの1つが

ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"

これにより、次のような名前のログファイルが多数発生します

-rw-r--r--    1 root     root         4078 Dec 21 01:04 error_log.1292457600
-rw-r--r--    1 root     root         4472 Dec 29 08:41 error_log.1293062400
-rw-r--r--    1 root     root        78630 Jan  4 12:57 error_log.1293667200
-rw-r--r--    1 root     root        15753 Jan 12 01:10 error_log.1294272000

apacheを再起動せずに表示されます。その後、それらを手動で圧縮できます。ローテーションが毎週、つまり604800秒ごとに行われることに注意してください。これはrotatelogsに渡される引数です。

アプリを停止して再起動できず、パイプ経由でログを記録できない場合は、本当の問題があると思います。おそらく他の人が提案をするでしょう。

2
MadHatter

logrotate全体を送信できれば非常に便利です。

なぜkill -HUPを使用しようとするのですか？ （クラシック再読み込み再起動ではない）メソッド。

また、ファイルにアクセスしているlsofを確認してください。

0
Nikolaidis Fotis