Subject: Re: postfix broken by AF_LOCAL semantics change
To: Jaromir Dolecek <>
From: Herb Peyerl <>
List: tech-kern
Date: 11/29/2003 07:03:16
Jaromir Dolecek <>  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)
	     * 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.
	    non_blocking(vstream_fileno(alloc->stream), BLOCKING);
			      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