On Sun, 12 Jan 2020 21:18:15 -0500 Scott Kitterman
<deb...@kitterman.com>
wrote:
On Sun, 17 Nov 2019 12:04:46 -0600 Andy Dorman
<ador...@ironicdesign.com>
wrote:
> Package: postfix
> Version: 3.4.7-2
> Severity: normal
>
> Dear Maintainer,
>
> We have several servers that run three instances of postfix on our own
hardware (not in a virtual machine environment).
>
> The enabled_instances() command from line 32 of the /etc/init.d/postfix
init
script shows the three instances:
Do you have multiple postfix master processes running? If so, where
are they
located?
Can you tell me the value of queue_directory for each instance?
Scott K
I've set up a docker image where I can use sysv init with multiple
instances
and they all start/stop fine. They were set up per the Postfix
MULTI_INSTANCE_README. I am unable to replicate your problem.
If you have multiple master processes running (not the standard
configuration),
then I can see how the new version might fail, but I can't make
progress on
this bug without input from you.
Scott K
Hello,
we got hit by this too during 10.2 to 10.3 update. Hotfixed it by
replacing running() function from the previous version of the init
script. (More on that below.)
Could you please clarify how having multiple master processes running is
not the standard configuration? Our multiple instance setup was created
according to Postfix MULTI_INSTANCE_README using these:
postmulti -e init
postmulti -e create -I postfix-fwd
and there has always been one master process per instance (same binary,
but multiple processes spawning off it.) Even with systemd as init
system, there is one master process per instance (just tested on Postfix
3.4.8-0+10debu1 on Debian 10.3)
About the running() function in the current 3.4.8 init script - in my
opinion its current form makes no sense. It's called with instance name
as parameter by the for cycle in start) and stop) cases for each
instance in the system. However, this line:
daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null || echo
/usr/lib/postfix/sbin)
is always returning the same directory: /usr/lib/postfix/sbin ,
regardless of the parameter passed to the function. Subsequent call to
/usr/lib/postfix/sbin/master -t then yields result regardless of the
parameter as well: it always returns the state of the main Postfix
instance, not the instance being checked by the caller.
Was there a reason to change this function? Previous version from 3.4.7
did the right thing here. Seemingly it even went beyong simple "pid file
exists" check that "master -t" does, and checked if the PID inside the
file exists and is Postfix's master process.
Also, considering this now affects stable and causes regression on
update, increasing severity might be warranted.
