Sstrhsrtj

I accidentally deleted the /var/log/mail file. Until that point I was able to monitor it using postfix stuff. Now, it seems that Postfix doesn't send its logs to /var/log/mail, since the file is not getting updated with new log messages.

When you delete mail.log file, rsyslog (on ubuntu) loose handle to file. To get it working back on Ubuntu, please give:

sudo service rsyslog restart

This will not only create new file but also start to write logs.

Even after creating an empty file

touch /var/log/mail

you have to restart the syslog

service syslog restart

and then it's logging gain :)

fwiw newer versions of postfix log to /var/log/mail.log and i also had to run sudo chmod a+w /var/log/mail* and service postfix restart to get my postfix logs back after deleting it

This is a bug in syslog, but illustrates a common issue when one deletes a file while it's open by a program. When you do an "rm ", you are removing a directory entry, but you are NOT removing the underlying file. The operating system keeps a count of references to the file, and will not actually delete the underlying file data until the reference count goes to zero. In the case of an average file, the reference count of the unopened file is one (the directory entry). When the file is opened, the count is incremented to two. If a second program opens the same file, the count will be incremented to three. If the directory entry is now deleted, the count is decremented to two -- which means that the file is anomymous (has no name), but will not be deleted until both programs which have it open close -- at which case the OS will delete the underlying disk storage associated with the file.

When you delete /var/log/mail, the system logger still has the file open for writing. If you create a new /var/log/mail, it will point to a file different from the one the system logger is currently writing. The only way to make everything consistent is to restart the system logger. When the original system logger terminates, all files associated with it are closed -- including the anonymous mail log whose directory entry you deleted. When you restart the system logger, it will re-open /var/log/mail when it needs to write a log message, and will keep it open thereafter.

Another way this is often discovered is when a running program fills up all of a disk with file data; the user deletes the very large file, but the disk space is not freed, because the file still exists, and is taking up disk space, but the directory entry has been removed. When the program ends (either because the user killed it or it ended itself), the disk space will be recovered because the reference count on the file will have gone to zero.

What the logger might do to prevent this is to first write the log message, check to see if the log file directory entry exists, and if it doesn't exist, close the original log file, open a new one, and then rewrite the message -- so that the message doesn't get lost. But to do all of that would require much more complexity than the system logger ought to have -- for each message it writes will take quite a bit longer to be written due to the extra directory check -- which will succeed every time the file has NOT been deleted.

To understand all of the above more clearly, the following command is instructive, for it describes the system call that performs the directory entry removal and the reference decrement: "man 3 unlink"

That's not the problem on CentOS 7. Someone thought it would be a great idea to have the postfix mail logs to go through the journaler. If you want to see postfix logs:

journalctl -u postfix

(to see whole log)

journalctl -u postfix -f

(to tail the log)

You may also need in the main.cf for postfix

syslog_name = postfix