Viktor Dukhovni:
> On Wed, Jan 26, 2022 at 11:22:53AM -0500, Wietse Venema wrote:
> 
> > Sorry, master -w" DOES fork (it's re-implemented with clone() on LINUX).
> > 
> >    -w     Wait in a dummy foreground process, while the real master daemon
> >       initializes in  a  background  process.   The  dummy  foreground
> >       process  returns  a  zero  exit status only if the master daemon
> >       initialization is successful, and if it completes in  a  reason-
> >       able amount of time.
> 
> Indeed you're right, sorry about the disparaging remark...
> 
> > I'll leave it to you to resolve this question.
> 
> :-(.
> 
> The OP can start by posting "postconf -nf" and "postconf -Mf" output,
> as well as any other maillog entries just above any of:
> 
>     postfix-authrelay/master[1179]: fatal: daemon initialization failure
>     postfix-inetgen/master[1195]: fatal: daemon initialization failure
>     postfix-authrelay/postfix-script[1404]: fatal: mail system startup failed
>     postfix-inetgen/postfix-script[1406]: fatal: mail system startup failed
> 
> As well as try to find relevant information in the trace.  As for
> "strace" complaining about "decode_nlattr()", I believe that's a
> Linux-issue in strace itself (perhaps the kernel and userland are not
> entirely matched up), and so ends up on stderr even with "strace -o
> file".

I'd like to add one thing: unfortunately the master babysitter
process currently does not distinguish between:

- The background daemon took too long to report that initialization
  is complete (the babysitter could log an ETIMEOUT error).

- The background daetmon (was) terminated without reporting that
  initialization is complete (the babysitter could log the termination
  status).

- The background daemon reported completion, and closed the channel
  before the babysitter had a chance to read the channel. Postfix
  has code in many places to wait-before-close, but the code in
  this particular place is relatively new and is less defensive.
  Every now and then someone improves kernel code and thinks that
  it is a good idea to make close-after-write destructive.

All of the above can be found out from strace output.

        Wietse

Reply via email to