Postfixが削除されて再作成された後、/ var / log / mailにログを記録しなくなりましたか？
/var/log/mailファイルを誤って削除してしまいました。それまでは、postfixを使って監視することができました。現在、ファイルが新しいログメッセージで更新されていないため、Postfixはログを/var/log/mailに送信しないようです。
Mail.logファイルを削除すると、（ubuntuでは）rsyslogがファイルへのハンドルを緩めます。 Ubuntuで動作させるには、次のように指定してください。
Sudo service rsyslog restart
これにより、新しいファイルが作成されるだけでなく、ログの書き込みも開始されます。
空のファイルを作成した後でも
touch /var/log/mail
syslogを再起動する必要があります
service syslog restart
そしてそれはロギングゲインです:)
これはsyslogのバグですが、プログラムで開いているときにファイルを削除した場合の一般的な問題を示しています。 「rm」を実行すると、ディレクトリエントリは削除されますが、基になるファイルは削除されません。オペレーティングシステムはファイルへの参照のカウントを保持し、参照カウントがゼロになるまで、実際に基になるファイルデータを削除しません。平均的なファイルの場合、開かれていないファイルの参照カウントは1（ディレクトリエントリ）です。ファイルが開かれると、カウントは2に増加します。 2番目のプログラムが同じファイルを開くと、カウントは3に増えます。ディレクトリエントリが削除されると、カウントは2に減少します。これは、ファイルが匿名である（名前がない）ことを意味しますが、ファイルを開いている両方のプログラムが閉じるまで削除されません。この場合、OSはファイルに関連付けられた基礎となるディスクストレージを削除します。
/ 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ログの新しいバージョンを/var/log/mail.logにfwiwし、Sudo chmod a+w /var/log/mail*とservice postfix restartも実行して、Postfixログを削除した後で元に戻す必要がありました。