MTA issue with Zimbra 7.1.3

[blason]

Hey Folks,

One fine morning I suddenly found that mta status though show Running in zmcontrol status, I was not able to connect to port 465 neither 25.

Then I verified the log entires and found below errors. any clue what must have gone wrong?

May 26 02:20:01 postfix/postqueue[24053]: fatal: Queue report unavailable - mail system is down
May 26 02:20:01 postfix/sendmail[24057]: warning: the Postfix sendmail command has set-uid root file permissions
May 26 02:20:01 postfix/sendmail[24057]: warning: or the command is run from a set-uid root process
May 26 02:20:01 postfix/sendmail[24057]: warning: the Postfix sendmail command must be installed without set-uid root file permissions
May 26 02:20:04 postfix/postqueue[24365]: fatal: Queue report unavailable - mail system is down

warning: the Postfix sendmail command must be installed without set-uid root file permissions

[rcanto]

Hi Blason.

I'm with the same problem. Did you resolve this problem? what was that?

Thank for your help.

Rodrigo

Hey Folks,

One fine morning I suddenly found that mta status though show Running in zmcontrol status, I was not able to connect to port 465 neither 25.

Then I verified the log entires and found below errors. any clue what must have gone wrong?

May 26 02:20:01 postfix/postqueue[24053]: fatal: Queue report unavailable - mail system is down
May 26 02:20:01 postfix/sendmail[24057]: warning: the Postfix sendmail command has set-uid root file permissions
May 26 02:20:01 postfix/sendmail[24057]: warning: or the command is run from a set-uid root process
May 26 02:20:01 postfix/sendmail[24057]: warning: the Postfix sendmail command must be installed without set-uid root file permissions
May 26 02:20:04 postfix/postqueue[24365]: fatal: Queue report unavailable - mail system is down

warning: the Postfix sendmail command must be installed without set-uid root file permissions

[kruon]

I'm running into same issue with zimbra 7.2 on random occasions.
Postfix just fails to start without logging any errors why.
I have nightly backup sequence scheduled to run at 1 which will stop and start zimbra.

My backup takes about 5 minutes to complete, so I'm trying to remedy the situation with following lines added to zimbra users crontab:

10 1 * * * grep "mail system is down" /var/log/zimbra.log -q && zmcontrol restart
20 1 * * * tail -n20 /var/log/zimbra.log | grep "mail system is down" -q && zmcontrol restart

At 1:10, check if there's "mail system is down" in zimbra.log, if exists, first startup of postfix failed at the end of backup and we now call zmcontrol restart.
Wait another 10 minutes and at 1:20 test if the end of zimbra.log still contains "mail system is down". If the second attempt to start zimbra at 1:10 worked, this line does nothing, else it'll call zmcontrol restart again.

I'm running this test in production now, but since the problem occurs completely random, I might have to wait a month to see if it actually works.

[kruon]

I might have to wait a month to see if it actually works.

Apparently not, my first attempt didn't help, now trying following lines placed in root crontab:

10 1 * * *      /bin/grep "mail system is down" /var/log/zimbra.log -q && sudo -u zimbra /opt/zimbra/bin/zmcontrol restart && logger -p local0.notice -t zimbra -- postfix seems to be down - running zmcontrol restart
20 1 * * *      /usr/bin/tail -n20 /var/log/zimbra.log | grep "mail system is down" -q && sudo -u zimbra /opt/zimbra/bin/zmcontrol restart && logger -p local0.notice -t zimbra -- postfix seems to be down - running zmcontrol restart

This should at least log the restart attempts.

[slasher]

Apparently not, my first attempt didn't help, now trying following lines placed in root crontab:
This should at least log the restart attempts.

We have experienced this same issue randomly a few times. Last time it occurred today morning when we found out that MTA/postfix component did not have started after an automatic backup script issued /etc/init.d/zimbra stop and finally /etc/init.d/zimbra start. For now on I just disabled zimbra restart sequence and using hot LVM snapshots until this issue can be solved, unfortunately there was no MTA related error messages in zimbra.log.