Sorry to say - it never got resolved. I believe it's an OS bug as I've
never seen it on other systems that I've run qmail on and the code looks
completely correct.
If you look at timeoutread.c you'll see that the code has issued the
read() as a consequence of the previous select() call indicating that the
fd can be read.
So I think you're stuck with it. Possibly an alarm wrapper of maybe a
script that sweeps for old qmail-smtpd processes might be a workaround.
Regards.
On Wed, Feb 02, 2000 at 04:38:53PM +0300, Anand Buddhdev wrote:
> I'm running qmail under Solaris 7 (aka solaris 2.7). I have a problem: I
> have many qmail-smtpd processes on the system which appear to have hung.
> Some of them are many days old, as old as Jan 17, 2000. I noticed them
> today when I saw that tcpserver's concurrency was quite high, yet there
> wasn't that much mail coming in. If I attach a truss to those processes,
> I see them "sleeping" on a read call:
>
> # truss -p 12270
> read(0, 0x0002A420, 1024) (sleeping...)
> ^C
> #
>
> I would have thought that they would timeout after 1200 seconds. I
> searched the archives and Mark Delany mentioned in
>
> http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/02/msg00752.html
>
> that he had seen a similar thing on Solaris 2.6, but there was no
> further discussion on a solution. At the moment, the only thing I can do
> is to kill off the processes by hand, or worse, reboot. Has anyone else
> seen this, and if so, is there a known solution? Is there any Solaris
> guru out there, who might know of a kernel parameter that I can tune to
> reduce this problem?
>
> --
> See complete headers for more info
