Postfix to manage its internal error in an explicit way

Question

I'm currently testing in lab a redundant/laod balancing setup where Keepalived health checks verifies that Postfix is running on 2 servers.

While Keepalived is working well, great convergence time and so on, it doesn't go very far in the SMTP dialog, it does an HELO, check that it receives a reply and that's it.

Given the complexity of Postfix, it might crash at various steps of the protocol dialog. Would it be possible to tell Postfix to crash asap, possibly before the HELO in the dialog. Of course, I'm sure we won't cover every scenario doing that but in some cases, Postfix might be able to tell imediately: I won't be able to handle your mail, go away.

For instance, if it has any ressources issues (partition full, unable to fork, whatever).

Does anybody have an idea about how to configure Postfix to act that way?

Thanks and regards,

Answer 1

Postfix is an error resistant software. It tries to recover from internal errors and normally the master itself won't die. So a single error/warning is not considered as a termination trigger and Postfix will continue running instead.

If you want to terminate Postfix on the first error/warning, you have to do it outside of Postfix. Watch the logfile for a warning you are interested in and then issue a "postfix stop". In this case no further connection attempt is possible and even the server greeting at port 25 is impossible. Please note that the only way to reactivate the Postfix system is to start it again manually.

But the scenario is then contra-productive. Your aim is to have a (two) running Postfix, but you kill one willingly. The second one could then be overloaded and gets killed, too. Let Postfix recover itself and monitor the postfix instances by counting log warnings instead of failed dummy SMTP connections.

If you don't monitor the logs you also can't identify errors like DNS resolution, increasing queues, connection exhausting, ...