/var/log/messages は、rsyslog から削除を許可しないため、無期限に増加します。

/var/log/messages は、rsyslog から削除を許可しないため、無期限に増加します。

5 GB パーティションに 2 GB ファイルのみを割り当てるように見えますが、/var スペース不足の問題があります。問題は/var/log/messagesが削除されましたが、rsyslogによってまだ開いていて2.88GBということです。

rsyslogを再起動して問題を解決できるので、2.8GBファイルを適切に削除できます。ところで、どうしてこんな状態になったのか気になります。ログが無限に大きくなるのを防ぐために、rsyslogは自動的にファイルを回転させるべきではありませんか?このようなことが再発しないように私ができることはありますか?

答え1

多くのディストリビューションでこれが機能する方法は、cronまたはsystemdタイマーで毎日呼び出されるlogrotateを介してです。 Logrotateは、/etc/logrotate.d例えば。/etc/logrotate.d/rsyslog/var/log/messages

/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}

ファイルが置き換えられたら、rsyslogを実行してrsyslogdに古いログファイルを閉じるように指示します(rsyslogを再起動して実行されるアクション/usr/lib/rsyslog/rsyslog-rotateSIGHUP。デーモンは再起動せずにファイルを閉じますSIGHUPrsyslogd(8) の「信号」部分

答え2

使用logrotate

マニュアルページの参照

logrotateは、コマンドラインで指定された一連の構成ファイルで処理する必要があるログファイルのすべての内容を読み取ります。各構成ファイルはグローバルオプションを設定し(ローカル定義はグローバルオプションをオーバーライドし、その後の定義は以前の定義をオーバーライドします)、回転するログファイルを指定できます。単純な構成ファイルは次のとおりです。

# sample logrotate configuration file
compress

/var/log/messages {
    rotate 5
    weekly
    postrotate
        /usr/bin/killall -HUP syslogd
    endscript
}

構成ファイルの次のセクションでは、ログファイル/var/log/messagesの処理方法を定義します。このログは削除される前に週に5回循環します。ログファイルが置き換えられた後(ただし、以前のバージョンのログが圧縮される前)、/sbin/killall -HUP syslogdコマンドが実行されます。

関連情報