[Users] Postfix Fails To Start On Reboot
Barry de Graaff
info at barrydegraaff.tk
Thu Jan 17 16:22:44 CET 2019
It looks like a fix for one of the bugs causing issues with the MTA has been sitting in a
pull request on the Zimbra Github for some time. The one with the PID not being an
[ https://github.com/Zimbra/zm-core-utils/pull/42 | https://github.com/Zimbra/zm-core-utils/pull/42 ]
That does not seem right!!
Barry de Graaff
Co-founder & Developer
zetalliance.org | github.com/Zimbra-Community
+31 617 220 227
From: "Jim Dunphy" <jad at aesir.com>
To: "L Mark Stone" <lmstone at lmstone.com>
Cc: users at lists.zetalliance.org
Sent: Monday, 14 January, 2019 17:56:14
Subject: Re: [Users] Postfix Fails To Start On Reboot
Sure sounds like this:
Bug number: ZBUG-798
Easy to reproduce.
----- On Jan 13, 2019, at 2:21 PM, L Mark Stone <lmstone at lmstone.com> wrote:
Several of us are seeing the issue where Postfix fails to restart on reboot. Randy I believe had some good information on this on a recent Zeta call.
So, this happened (again) to me today, and I did my usual zmmtactl stop, move the ~/data/postfix/spool/pid /master.pid someplace, then zmmtactl start (which gets saslauthd started but not postfix) then "postfix stop" and "postfix start" and everything is OK again. All commands executed as the Zimbra user.
Except now I'm seeing the ownership permissions of ~/data/postfix/spool/pid all over the place, so asking what others are seeing and what should the ownership be?
On one system that has never had an issue with Postfix restarting, all of the files are owned by postfix:postfix with 600 perms.
On the system where I just executed my hack, the master.pid, unix.error and unix.trace files are owned by root:root (with all other files owned by postfix:postfix). The old master.pid was owned by postfix:postfix.
On another system which has had this issue intermittently, unix.trace is owned by root:root and everything else by postfix:postfix.
So before I open a Support Case with Zimbra, I thought I'd ask here what others are seeing, and what your workaround has been.
Another Message From... L. Mark Stone
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users