Sorry for not answering earlier, been quite busy the past few days.
@Habitual
As Ser Olmy pointed out, a simple TCP connect is not enough for us, we really want Postfix to respond to our probes
@Ser Olmy
Thanks for getting into this. I tried you interesting idea of setting a debug_peer_level of 0, unfortunately without luck:
After a postfix reload I get: postfix: fatal: invalid debug_peer_level parameter value 0 < 1
And yes, I figured that cleaning the live log with any sort of hack would not be such a great idea. Apart from being a dirty hack, I would also have to stop postfix before I could even touch the log, which I learned later, and that's definitely a show stoper. Well, I was frustrated and thought, that the hammer tactics might be a suitable solution of a last resort in this special case ;-)
@MadeInGermany
We could argue what is the "right" timing to probe a service, but that doesn't solve the issue, it just reduces the amount of log entries.
Since we also want to catch short outages, we rather leave it at 30 sec with 30 sec retry.
But thanks for adding your view.
What next?
----------
I'll have a look at the syslogd options. Maybe there is something I can use in order to strip the lines in question or maybe pipe the output somewhere else, strip the crap and re-inject it to syslogd and have it then delivered to the postfix maillog. But then again, that's again some sort of hack, which is probably pure overkill just to get rid a few log entries...
If that doesn't help, I'll probably go with a solution similar to the one outlined here:
http://stackoverflow.com/questions/1...-write-maillog
I won't touch the live logs, promised ;-)
Rather setting up some cron job to copy the live logs to a working directory every now and then and then have the above linked solution applied in order to strip the logs from the bloat.
If anyone has a better solution, I'm all ears.
Thanks all for you assistance so far, much appreciated.
Cheers
Juri