On Thu, Jun 07, 2001 at 07:36:53PM +0200, J�rgen Persson allegedly wrote:
> Sorry, but I'm not all comfortable with this...
>
> There's been 4 similar reports of qmail-remote not behaving properly to
> this list during the last month.
>
> http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg00558.html
> http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg01332.html
> http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/06/msg00283.html
> http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/06/msg00426.html
>
> We still haven't been able to help any of them...
>
> This doesn't look like a coincidence to me since two of the reports
> concerned the same recipient server (outblaze.com). Unfortunately it
> seems related to network programming, which I know very little about.
>
> Any other thoughts about this?
If it's an unpatched qmail-remote, then remain suspicious of some OS
bug. I spent a long time looking at qmail-remote when a similar
problem occured on a Solaris 2.5 system (or maybe 2.6, I forget
now). Here are the two lines of code:
if (select(fd + 1,&rfds,(fd_set *) 0,(fd_set *) 0,&tv) == -1) return -1;
if (FD_ISSET(fd,&rfds)) return read(fd,buf,len);
That's about as simple as you can get!
I don't see any way that the read() call will occur without select()
returning the fdset bit. So, if select() says that a read can occur,
then the only reason that the read() can then block is if the OS is
lying...
So, it's kinda hard to see a problem with qmail-remote here. Do OSes
ever get it wrong? Sure.
If this is a relatively widespread problem, then you might want to put
an alarm() handler into qmail-remote, but if you can't rely on the OS,
all bets are really off, right?
Regards.
