削除して再作成した後、Postfixは/ var / log / mailにログを記録しなくなりましたか？

誤って/var/log/mailファイルを削除してしまいました。それまでは、postfixを使用して監視することができました。現在、/var/log/mailファイルが新しいログメッセージで更新されていないため、Postfixはログをに送信しないようです。

mail.logファイルを削除すると、（ubuntuでは）rsyslogがファイルへのハンドルを緩めます。Ubuntuで動作させるには、次のように指定してください。

sudo service rsyslog restart

これにより、新しいファイルが作成されるだけでなく、ログの書き込みも開始されます。

空のファイルを作成した後でも

touch /var/log/mail

syslogを再起動する必要があります

service syslog restart

そしてそれはロギングゲインです:)

これはsyslogのバグですが、プログラムで開いているときにファイルを削除すると、一般的な問題が発生します。「rm」を実行すると、ディレクトリエントリが削除されますが、基になるファイルは削除されません。オペレーティングシステムはファイルへの参照の数を保持し、参照カウントがゼロになるまで、実際に基になるファイルデータを削除しません。平均的なファイルの場合、開かれていないファイルの参照カウントは1（ディレクトリエントリ）です。ファイルが開かれると、カウントは2に増加します。2番目のプログラムが同じファイルを開くと、カウントは3に増えます。ディレクトリエントリが削除された場合、カウントは2に減少します。これは、ファイルが匿名である（名前がない）ことを意味します。

/ var / log / mailを削除しても、システムロガーは書き込み用にファイルを開いたままにします。新しい/ var / log / mailを作成すると、システムロガーが現在書き込んでいるファイルとは異なるファイルを指します。すべてを一貫させる唯一の方法は、システムロガーを再起動することです。元のシステムロガーが終了すると、それに関連付けられているすべてのファイル（ディレクトリエントリを削除した匿名のメールログを含む）が閉じられます。システムロガーを再起動すると、ログメッセージを書き込む必要があるときに/ var / log / mailが再度開き、その後も開いたままになります。

これがよく発見されるもう1つの方法は、実行中のプログラムがディスク全体をファイルデータで満たす場合です。ユーザーは非常に大きなファイルを削除しますが、ファイルがまだ存在し、ディスクスペースを占有しているため、ディスクスペースは解放されませんが、ディレクトリエントリは削除されています。プログラムが終了すると（ユーザーがプログラムを強制終了したか、プログラムが終了したため）、ファイルの参照カウントがゼロになったため、ディスク領域が回復します。

これを防ぐためにロガーが行うことは、最初にログメッセージを書き込み、ログファイルのディレクトリエントリが存在するかどうかを確認し、存在しない場合は、元のログファイルを閉じ、新しいログファイルを開いてから、メッセージ-メッセージが失われないようにします。ただし、これらすべてを行うには、システムロガーが持つべきよりもはるかに複雑な処理が必要になります。追加のディレクトリチェックにより、メッセージが書き込まれるたびに書き込まれるまでにかなり時間がかかります。削除されていません。

上記のすべてをより明確に理解するには、次のコマンドが役立ちます。これは、ディレクトリエントリの削除と参照の減少を実行するシステムコールを説明しているためです： "man 3 unlink"

それはCentOS 7の問題ではありません。誰かがpostfixメールログをジャーナラーに通過させるのは素晴らしいアイデアだと誰かが考えました。postfixログを見たい場合：

journalctl -u postfix

（ログ全体を見るため）

journalctl -u postfix -f

（ログをテールするため）

postfixのmain.cfも必要になる場合があります

syslog_name = postfix

Postfixログの新しいバージョンをfwiw /var/log/mail.logし、実行sudo chmod a+w /var/log/mail*しservice postfix restartて、Postfixログを削除した後に戻す必要がありました