Subject: Re: postfix broken by AF_LOCAL semantics change
To: Jaromir Dolecek <jdolecek@NetBSD.org>
From: Herb Peyerl <email@example.com>
Date: 11/29/2003 07:03:16
Jaromir Dolecek <jdolecek@NetBSD.org> wrote:
> Matt Thomas wrote:
> > If connect succeed with any backpressure (as is the default behavior),
> > then it quite easy for a swarm of requests to overwhelm an accepting
> > server since his backlog can be exceeded before he even gets scheduled
> > to run. If you make the connect sleep until accepted, you can limit the
> > overruns. Part of the problem is that when the backlog is exceeded the
> > error is ECONNREFUSED. This makes it impossible for a client to
> > determine
> > whether it was because there was no socket bound to the right name or
> > that
> > socket accept queue became full.
> This sounds reasonable and I don't see any API incompatibility
> in this. Everyone agrees that connect() can block, right?
> What exact API incompatibility you are referring to, Perry?
> Doesn't postfix do something stupid such as assuming connect
> to AF_LOCAL won't block?
> Of course, the clients should only be put to sleep if the
> socket is open in blocking (default) mode. Does your code
> work this way, Matt?
Looks like one can build postfix with this:
/* qmgr_transport_connect - handle connection request completion */
static void qmgr_transport_connect(int unused_event, char *context)
QMGR_TRANSPORT_ALLOC *alloc = (QMGR_TRANSPORT_ALLOC *) context;
* This code is necessary for some versions of LINUX, where connect(2)
* blocks until the application performs an accept(2). Reportedly, the
* same can happen on Solaris 2.5.1.
qmgr_transport_event, (char *) alloc);
I haven't succeeded in making /usr/pkgsrc/mail/postfix actually start
up as an alternate postfix on my affected server so I haven't confirmed