On 11. 02. 20 19:33, Scott Kitterman wrote:
On Tuesday, February 11, 2020 12:35:16 PM EST jaros...@thinline.cz
wrote:
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.
There are environments where the old approach didn't work. I had
intended to
work on this sooner, but ran out of time. Changing priority won't give
me
more time to work on Postfix in Debian. This is the next thing I plan
to do.
The current version replicates the upstream approach, but obviously
something
else is different. My intent is to got back to the previous version of
the
function by default and only use the new one if /proc isn't accessible
(which
is the original problem I was trying to solve).
Sorry for the inconvenience.
Scott K
Hello,
thanks for putting your time into this.
If it helps, I made a quick and dirty fix to the new approach
running() {
INSTANCE="$1"
if [ "X$INSTANCE" = X ]; then
POSTMULTI=""
else
POSTMULTI="postmulti -i $INSTANCE -x "
fi
POSTCONF="${POSTMULTI} postconf"
daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null ||
echo /usr/lib/postfix/sbin)
if ! ${POSTMULTI} $daemon_directory/master -t 2>/dev/null ; then
echo y
fi
}
This way postmulti calls master (or any program) with some environment
variables set, namely [1]:
MAIL_LOGTAG=postfix
MAIL_CONFIG=/etc/postfix-fwd
daemon_directory=/usr/lib/postfix/sbin
command_directory=/usr/sbin
config_directory=/etc/postfix-fwd
queue_directory=/var/spool/postfix-fwd
data_directory=/var/lib/postfix-fwd
multi_instance_name=postfix-fwd
multi_instance_group=
multi_instance_enable=yes
Apparently master process uses these and does the right thing, ie. looks
for the pidfile in correct directory - see strace:
[pid 8180] chdir("/var/spool/postfix-fwd") = 0
[pid 8180] access("pid/master.pid", F_OK) = 0
I admit I have no idea whatsoever if this approach is correct,
documented or supported. Just occured to me it might work and it did.
[1] postmulti -i postfix-fwd -x cat /proc/self/environ | tr "\0" "\n"
