Re: PATCH: non-Postfix processes in init mode
Sure, I must suck at expressing myself as well. Not only had it been
left intact and moved into the conditional construct, it had still been
there without that in addition, thereby defeating the very purpose of
patching. Like I said, contrary to what I might seem, I'm no moron and
I've realized the mistake when You told me the behaviour didn't seem
like being patched in the first place. I've since then corrected my
patch, applied, compiled and packaged it, imaged it and am running it -
and it works. I'm grateful!
On 2019. 02. 18. 20:41, Wietse Venema wrote:
> Tam?s G?rczei:
>> Indeed, I should have had some rest before applying your patch... I did
>> create the condition, branching on init mode towards continue as
>> intended, yet also left the original call there right thereafter :D It
> You MUST KEEP the original panic call, like this:
>
> if ((proc = (MASTER_PROC *) binhash_find(master_child_table,
> (void *) , sizeof(pid))) == 0) {
> if (init_mode)
> continue; /* non-Postfix process */
> msg_panic("master_reap: unknown pid: %d", pid);
> }
Re: PATCH: non-Postfix processes in init mode
Tam?s G?rczei:
> Indeed, I should have had some rest before applying your patch... I did
> create the condition, branching on init mode towards continue as
> intended, yet also left the original call there right thereafter :D It
You MUST KEEP the original panic call, like this:
if ((proc = (MASTER_PROC *) binhash_find(master_child_table,
(void *) , sizeof(pid))) == 0) {
if (init_mode)
continue; /* non-Postfix process */
msg_panic("master_reap: unknown pid: %d", pid);
}
Re: PATCH: non-Postfix processes in init mode
Indeed, I should have had some rest before applying your patch... I did
create the condition, branching on init mode towards continue as
intended, yet also left the original call there right thereafter :D It
applied and compiled well and I was sure I used the new packages and
image so I was reluctant to follow along. Now I have retraced my steps
and looked at the code after applying my mangled patch and everything
became very obvious. Thank You for pointing it out!
On 2019. 02. 18. 17:36, Wietse Venema wrote:
> Tam?s G?rczei:
>> 1 root 0:00 /usr/libexec/postfix/master -i
>> ...
>> 78 postfix 0:00 smtpd -n smtp -t inet -u -o stress=
>>
>> Feb 18 09:36:57 mail-postfix-0 postfix/master[1]: panic: master_reap:
>> unknown pid: 78*
>>> + if (init_mode)
>>> + continue; /* non-Postfix process */
>>> msg_panic("master_reap: unknown pid: %d", pid);
> You are not running a correctly patched master daemon. Your code
> probably looks like this:
>
> if (init_mode)
> msg_panic("master_reap: unknown pid: %d", pid);
>
> That is consistent with your logging and 'ps' output.
>
> Wietse
Re: PATCH: non-Postfix processes in init mode
Tam?s G?rczei:
> 1 root 0:00 /usr/libexec/postfix/master -i
>...
> 78 postfix 0:00 smtpd -n smtp -t inet -u -o stress=
>
> Feb 18 09:36:57 mail-postfix-0 postfix/master[1]: panic: master_reap:
> unknown pid: 78*
> > + if (init_mode)
> > + continue; /* non-Postfix process */
> > msg_panic("master_reap: unknown pid: %d", pid);
You are not running a correctly patched master daemon. Your code
probably looks like this:
if (init_mode)
msg_panic("master_reap: unknown pid: %d", pid);
That is consistent with your logging and 'ps' output.
Wietse
Re: PATCH: non-Postfix processes in init mode
So I've now configured init mode in foreground with logging properly on
stdout and your patch applied to the last 3.5 snapshot and I got the
same panic, although this time not against my piped spamd process,
rather smtpd, it would appear:
/ # ps
PID USER TIME COMMAND
1 root 0:00 /usr/libexec/postfix/master -i
75 postfix 0:00 pickup -l -t unix -u
76 postfix 0:00 qmgr -l -t unix -u
77 postfix 0:00 postlogd -l -n postlog -t unix-dgram -u
* 78 postfix 0:00 smtpd -n smtp -t inet -u -o stress=*
79 postfix 0:00 tlsmgr -l -t unix -u
80 postfix 0:00 anvil -l -t unix -u
81 postfix 0:00 trivial-rewrite -n rewrite -t unix -u
82 postfix 0:00 spawn -z -n policyd-spf -t unix user=policyd-spf
argv=/usr/bin/policyd-spf /policyd-spf/config/policyd-spf.conf
83 policyd- 0:01 {policyd-spf} /usr/bin/python3.6
/usr/bin/policyd-spf /policyd-spf/config/policyd-spf.conf
84 postfix 0:00 cleanup -z -t unix -u
85 postfix 0:00 pipe -n spamassassin -t unix user=spamc
argv=/usr/bin/spamc -d mail-spamassassin-0.mail-spamassassin-service -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
89 postfix 0:00 lmtp -t unix -u
90 root 0:00 /bin/sh
97 root 0:00 ps
/ # command terminated with exit code 137
tgerczei@altar ~ $ kc logs po/mail-postfix-0 -f
Feb 18 09:33:39 mail-postfix-0 postfix/postfix-script[63]: warning:
group or other writable: /postfix/config-live/.
Feb 18 09:33:39 mail-postfix-0 postfix/postfix-script[74]: starting the
Postfix mail system
Feb 18 09:33:39 mail-postfix-0 postfix/master[1]: daemon started --
version 3.5-20190212, configuration /postfix/config-live
Feb 18 09:35:14 mail-postfix-0 postfix/smtpd[78]: connect from
mail-qt1-f182.google.com[209.85.160.182]
Feb 18 09:35:15 mail-postfix-0 postfix/smtpd[78]: Anonymous TLS
connection established from mail-qt1-f182.google.com[209.85.160.182]:
TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Feb 18 09:35:15 mail-postfix-0 postfix/smtpd[78]: NOQUEUE: filter: RCPT
from mail-qt1-f182.google.com[209.85.160.182]:
: Sender address triggers FILTER
spamassassin:dummy; from= to=
proto=ESMTP helo=
Feb 18 09:35:17 mail-postfix-0 postfix/smtpd[78]: 63C912D0E6C:
client=mail-qt1-f182.google.com[209.85.160.182]
Feb 18 09:35:17 mail-postfix-0 postfix/cleanup[84]: 63C912D0E6C:
message-id=
Feb 18 09:35:17 mail-postfix-0 postfix/qmgr[76]: 63C912D0E6C:
from=, size=2872, nrcpt=1 (queue active)
Feb 18 09:35:17 mail-postfix-0 postfix/smtpd[78]: disconnect from
mail-qt1-f182.google.com[209.85.160.182] ehlo=2 starttls=1 mail=1 rcpt=1
bdat=1 quit=1 commands=7
Feb 18 09:35:27 mail-postfix-0 postfix/pickup[75]: DBB5F2D0E71: uid=103
from=
Feb 18 09:35:27 mail-postfix-0 postfix/pipe[85]: 63C912D0E6C:
to=, relay=spamassassin, delay=13,
delays=2.2/0.02/0/10, dsn=2.0.0, status=sent (delivered via spamassassin
service)
Feb 18 09:35:27 mail-postfix-0 postfix/qmgr[76]: 63C912D0E6C: removed
Feb 18 09:35:27 mail-postfix-0 postfix/cleanup[84]: DBB5F2D0E71:
message-id=
Feb 18 09:35:29 mail-postfix-0 postfix/qmgr[76]: DBB5F2D0E71:
from=, size=3497, nrcpt=1 (queue active)
Feb 18 09:35:29 mail-postfix-0 postfix/lmtp[89]: DBB5F2D0E71:
to=,
relay=mail-dovecot-0.mail-dovecot-service.default.svc.cluster.local[10.244.1.53]:54321,
delay=2.9, delays=2.7/0.03/0.05/0.12, dsn=2.0.0, status=sent (250 2.0.0
y4PZF2F8alx7GwAAHo2YKg Saved)
Feb 18 09:35:29 mail-postfix-0 postfix/qmgr[76]: DBB5F2D0E71: removed
*Feb 18 09:36:57 mail-postfix-0 postfix/master[1]: panic: master_reap:
unknown pid: 78*
I don't get this since smtpd had surely been spawned by master. Should I
have used 3.4? Does 3.5 have anything new in there in this regard?
(Anything below 3.4 wouldn't support logging to stdout, hence my choice.)
On 2019. 02. 17. 15:42, Wietse Venema wrote:
> Wietse Venema:
>> Tam?s G?rczei:
>>> Hello List,
>>>
>>> I'd like to ask whether You're aware of any change which might cause
>>> breakage in my setup involving spamc with a completely unchanged
>>> configuration in between - I'm getting the following error:
>>>
>>> *"panic: master_reap: unknown pid"*
>> Is the Postfix master daemon running as PID 1? Historically this
>> PID was reserved for the init daemon which becomes the parent of
>> orphaned processes, i.e. processes that terminate without a parent
>> waiting for them. Postfix does not create such processes, but if
>> you run other programs inside the Postfix container then they
>> might do that.
>>
>> Options:
>>
>> - Run Postfix as PID != 1.
>>
>> - Don't co-locate Postfix with other software. That means pipe into
>> socket instead of into a program in the same container.
>>
>> - Make the master sloppier, and accept events from processes that
>> it did not create.
> As per the patch below.
>
> --- src/master/master_spawn.c-2014-12-06 20:35:33.0 -0500
> +++ src/master/master_spawn.c 2019-02-17 09:38:52.0 -0500
> @@ -301,8 +301,11 @@
> if (msg_verbose)
> msg_info("master_reap_child: pid
Re: PATCH: non-Postfix processes in init mode
Tam?s G?rczei: > Thanks Wietse, I'll definitely try this patch -? but this code didn't > change in quite a bit of time. If in doubt, look RTFM the Postfix 3.3.1 announcement. * Postfix did not support running as a PID=1 process, which complicated Postfix management in containers. The "postfix start-fg" command will now run the Postfix master daemon as a PID=1 process if possible. Thanks to inputs from Andreas Schulze, Eray Aslan, and Viktor Dukhovni. Wietse
Re: PATCH: non-Postfix processes in init mode
Hm.. Thanks to You both, I'll go take a look at this. On 2019. 02. 17. 16:14, Wietse Venema wrote: > Tam?s G?rczei: >> Thanks Wietse, I'll definitely try this patch -? but this code didn't >> change in quite a bit of time. > If in doubt, look RTFM the Postfix 3.3.1 announcement. > > * Postfix did not support running as a PID=1 process, which > complicated Postfix management in containers. The "postfix > start-fg" command will now run the Postfix master daemon as a > PID=1 process if possible. Thanks to inputs from Andreas Schulze, > Eray Aslan, and Viktor Dukhovni. > > Wietse
Re: PATCH: non-Postfix processes in init mode
Am 17.02.19 um 16:01 schrieb Tamás Gérczei: > Anyway I'm invoking postfix-script in order to start master: I wonder why you don't use "postfix start-fg" available since postfix-3.3.1 (http://www.postfix.org/announcements/postfix-3.3.1.html) Andreas
Re: PATCH: non-Postfix processes in init mode
Thanks Wietse, I'll definitely try this patch - but this code didn't
change in quite a bit of time. Can this behaviour I'm seeing somehow
relate to a change introduced between 3.3.0 and 3.3.2 ? I have zero
problems with the exact same setup and configuration on 3.3.0. Anyway
I'm invoking postfix-script in order to start master:
/ # ps auxwww -o pid,ppid,user,time,comm
PID PPID USER TIME COMMAND
1 0 root 0:00 postfix-script
9 1 root 0:01 rsyslogd
92 1 root 0:00 master
94 92 postfix 0:00 qmgr
96 92 postfix 0:00 tlsmgr
235 92 postfix 0:00 pickup
275 0 root 0:00 sh
283 92 postfix 0:00 smtpd
284 92 postfix 0:00 anvil
286 275 root 0:00 ps
T.
On 2019. 02. 17. 15:42, Wietse Venema wrote:
> Wietse Venema:
>> Tam?s G?rczei:
>>> Hello List,
>>>
>>> I'd like to ask whether You're aware of any change which might cause
>>> breakage in my setup involving spamc with a completely unchanged
>>> configuration in between - I'm getting the following error:
>>>
>>> *"panic: master_reap: unknown pid"*
>> Is the Postfix master daemon running as PID 1? Historically this
>> PID was reserved for the init daemon which becomes the parent of
>> orphaned processes, i.e. processes that terminate without a parent
>> waiting for them. Postfix does not create such processes, but if
>> you run other programs inside the Postfix container then they
>> might do that.
>>
>> Options:
>>
>> - Run Postfix as PID != 1.
>>
>> - Don't co-locate Postfix with other software. That means pipe into
>> socket instead of into a program in the same container.
>>
>> - Make the master sloppier, and accept events from processes that
>> it did not create.
> As per the patch below.
>
> --- src/master/master_spawn.c-2014-12-06 20:35:33.0 -0500
> +++ src/master/master_spawn.c 2019-02-17 09:38:52.0 -0500
> @@ -301,8 +301,11 @@
> if (msg_verbose)
> msg_info("master_reap_child: pid %d", pid);
> if ((proc = (MASTER_PROC *) binhash_find(master_child_table,
> - (void *) , sizeof(pid))) == 0)
> + (void *) , sizeof(pid))) == 0) {
> + if (init_mode)
> + continue; /* non-Postfix process */
> msg_panic("master_reap: unknown pid: %d", pid);
> + }
> serv = proc->serv;
>
> #define MASTER_KILL_SIGNAL SIGTERM
PATCH: non-Postfix processes in init mode
Wietse Venema:
> Tam?s G?rczei:
> > Hello List,
> >
> > I'd like to ask whether You're aware of any change which might cause
> > breakage in my setup involving spamc with a completely unchanged
> > configuration in between - I'm getting the following error:
> >
> > *"panic: master_reap: unknown pid"*
>
> Is the Postfix master daemon running as PID 1? Historically this
> PID was reserved for the init daemon which becomes the parent of
> orphaned processes, i.e. processes that terminate without a parent
> waiting for them. Postfix does not create such processes, but if
> you run other programs inside the Postfix container then they
> might do that.
>
> Options:
>
> - Run Postfix as PID != 1.
>
> - Don't co-locate Postfix with other software. That means pipe into
> socket instead of into a program in the same container.
>
> - Make the master sloppier, and accept events from processes that
> it did not create.
As per the patch below.
--- src/master/master_spawn.c- 2014-12-06 20:35:33.0 -0500
+++ src/master/master_spawn.c 2019-02-17 09:38:52.0 -0500
@@ -301,8 +301,11 @@
if (msg_verbose)
msg_info("master_reap_child: pid %d", pid);
if ((proc = (MASTER_PROC *) binhash_find(master_child_table,
- (void *) , sizeof(pid))) == 0)
+ (void *) , sizeof(pid))) == 0) {
+ if (init_mode)
+ continue; /* non-Postfix process */
msg_panic("master_reap: unknown pid: %d", pid);
+ }
serv = proc->serv;
#define MASTER_KILL_SIGNAL SIGTERM
