我不小心删除了该/var/log/mail文件。直到那时我才能够使用 postfix 的东西来监视它。现在，Postfix 似乎不会将其日志发送到/var/log/mail，因为该文件没有使用新的日志消息进行更新。
答案1
当您删除 mail.log 文件时，rsyslog（在 ubuntu 上）会释放文件句柄。要让它在 Ubuntu 上恢复正常工作，请给出：
sudo service rsyslog restart
这不仅会创建新文件，还会开始写入日志。
答案2
即使创建空文件后
touch /var/log/mail
你必须重新启动系统日志
service syslog restart
然后记录增益:)
答案3
这是系统日志中的一个错误，但说明了在程序打开文件时删除该文件时的一个常见问题。当您执行“rm”时，您将删除目录条目，但不会删除底层文件。操作系统保留对文件的引用计数，并且在引用计数变为零之前不会实际删除底层文件数据。对于普通文件来说，未打开文件的引用计数是1（目录项）。打开文件时，计数会增加到 2。如果第二个程序打开同一个文件，计数将增加到三。如果现在删除目录条目，则计数将减少到 2——这意味着该文件是匿名的（没有名称），但直到打开该文件的两个程序都关闭时才会被删除——在这种情况下，操作系统将删除与该文件关联的底层磁盘存储。
当您删除 /var/log/mail 时，系统记录器仍然打开该文件进行写入。如果您创建一个新的 /var/log/mail，它将指向一个与系统记录器当前正在写入的文件不同的文件。使一切保持一致的唯一方法是重新启动系统记录器。当原始系统记录器终止时，与其关联的所有文件都将关闭 - 包括您删除了其目录条目的匿名邮件日志。当您重新启动系统记录器时，它会在需要写入日志消息时重新打开/var/log/mail，并在之后保持打开状态。
经常发现这种情况的另一种方式是当正在运行的程序用文件数据填满整个磁盘时；用户删除了非常大的文件，但磁盘空间并未释放，因为该文件仍然存在，并且正在占用磁盘空间，但目录项已被删除。当程序结束时（因为用户杀死了它或者程序自行结束），磁盘空间将被恢复，因为文件的引用计数将变为零。
为了防止这种情况，记录器可能会做的就是首先写入日志消息，检查日志文件目录条目是否存在，如果不存在，则关闭原始日志文件，打开一个新的日志文件，然后重写消息——这样消息就不会丢失。但要做到这一切，需要比系统记录器应有的复杂性多得多——对于它写入的每条消息，由于额外的目录检查，它会花费相当长的时间来写入——每次文件完成时都会成功没有被删除。
为了更清楚地理解上述所有内容，以下命令很有启发性，因为它描述了执行目录条目删除和引用递减的系统调用：“man 3 unlink”
答案4
fwiw 新版本的 postfix 日志到/var/log/mail.log，我还必须运行sudo chmod a+w /var/log/mail*并service postfix restart在删除后恢复我的 postfix 日志