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
signature.asc
Description: This is a digitally signed message part.
