誤ってファイルを削除しました/var/log/mail。それまではpostfixを使って監視できました。これで/var/log/mail、ファイルが新しいログメッセージで更新されないため、Postfixはログを送信しないようです。
答え1
mail.logファイルを削除すると、rsyslog（Ubuntuから）がファイルハンドルを解放します。 Ubuntuで再び正常に機能させるには、次のように入力します。
sudo service rsyslog restart
これにより、新しいファイルが作成されるだけでなく、ログへの書き込みも開始されます。
答え2
空のファイルを作成した後でも
touch /var/log/mail
syslogを再起動する必要があります。
service syslog restart
その後、ゲインを記録します:)
答え3
これはシステムログのエラーですが、ファイルが開いている間にプログラムがファイルを削除したときに発生する一般的な問題を示しています。 「rm」を実行すると、ディレクトリエントリは削除されますが、デフォルトファイルは削除されません。オペレーティングシステムはファイルの参照カウントを保持し、参照カウントがゼロに達するまで基本ファイルデータを実際に削除しません。一般ファイルの場合、開かれていないファイルの参照数は1（ディレクトリエントリ）です。ファイルが開くと、数が2に増加します。 2番目のプログラムが同じファイルを開くと、数は3つに増えます。今すぐディレクトリエントリを削除すると、カウントが2に減少します。つまり、ファイルは匿名（名前なし）ですが、そのファイルを開いた両方のプログラムが閉じられるまで削除されません。この場合、オペレーティングシステムはデフォルトエントリを削除します。ファイルに関連付けられたディスクストレージ。
/var/log/mailを削除しても、システムロガーは書き込みを続けるためにファイルを開きます。新しい/var/log/mailを作成すると、システムロガーは現在書き込んでいるファイルとは異なるファイルを指します。すべてを一貫させる唯一の方法は、システムロガーを再起動することです。元のシステムロガーが終了すると、ディレクトリエントリを削除した匿名メールログを含む、それに関連するすべてのファイルが閉じられます。システムロガーを再起動すると、ログメッセージを作成する必要があるときに/var/log/mailが再び開き、それ以降は開いたままになります。
これがよく見られるもう1つの方法は、実行中のプログラムがディスク全体をファイルデータで埋める場合です。ユーザーは非常に大きなファイルを削除しましたが、ファイルがまだ存在し、ディスク領域を占有しているため、ディスク領域は解放されません。ディレクトリエントリが削除されました。プログラムが終了すると（ユーザーがプログラムを終了するか、プログラム自体を終了して）、ファイルの参照カウントが0になるため、ディスク容量が回復します。
これを防ぐためにロガーが実行できるのは、まずログメッセージを作成し、ログファイルディレクトリエントリがあることを確認してから、そうでない場合は元のログファイルを閉じて新しいログファイルを開き、メッセージを再構築することです。メッセージは失われません。ただし、これをすべて実行するには、システムロガーが持っている必要があるよりもはるかに複雑な作業が必要です。記録するすべてのメッセージについて記録するのにかなりの時間がかかります。追加のディレクトリチェックにより、ファイルは正常に完了し、削除されません。 。
上記のすべてをより明確に理解するために、次のコマンドは、ディレクトリエントリの削除と参照の削減を実行するシステムコールを説明しているため、有益です。 「man 3 unlink」
答え4
新しいバージョンのpostfixログが到着しましたが、削除後にpostfixログを実行して復元する/var/log/mail.log必要がありました。sudo chmod a+w /var/log/mail*service postfix restart