> Setting an alarm is a nasty hack in my opinion, but I have to admit
> that it's something I considered.
Well, the qmail-remote connection is well and truly wedged once it's
in this state and if the select() timed out as it's meant to,
qmail-remote would exit with a delivery failure indication, so it's
not that bad a hack. It's also very easy to code - just a single
alarm() call at teh top of main().
> A slightly neater solution might be to use
> the SO_KEEPALIVE socket option - if it works (and there isn't a good reason
> not to use it) that is.
It'll be interesting to hear if this works.
> What would be better is finding out why this happens, of course.
Indeed. Does Linux offer tools/syscalls that would tell you why the
select worked, but the read failed?
> P.S. If anyone is keeping track, Linux 2.2.19, concurrencyremote set to 200
I hesitate to say this, but Linux kernels seem to predominate in this
regard, but that just may be that qmail is running on more Linux out
there than other Unixen.
Regards.
