Victor Duchovni:
> On Thu, Sep 25, 2008 at 11:49:33AM -0400, Wietse Venema wrote:
>
> > In your case, the smtpd process gets stuck, the cleanup process
> > gives up after waiting for one hour, and then the smtpd process
> > becomes un-stuck more than 9 minutes later. In the mean time, the
> > SMTP client and the cleanup process have gone away, but of course
> > the smtpd process discovers that only after it becomes un-stuck.
> >
> > I have no idea why the smtpd process would get stuck except of
> > course for kernel bugs.
>
> Or network data dribbling in very slowly, so that smtpd is not so much
> stuck as swimming through a tarpit. To discover which, a (full packet
> binary) tcpdump capture is required.
I wonder if the machine is running something that slows down traffic
that looks "suspicious" to a data rate of 1 byte/s.
Consider the following:
- The DATA command happens around 06:52:07, and at 08:01:48 the
smtpd process discovers that the cleanup server has gone away.
That would correspond with 4096 bytes in 4181 seconds. This is so
close to 1 byte/s that I wonder if it is a concidence.
> Sep 24 06:52:08 barattolo postfix/smtpd[5832]: 2928F10000E:
> client=squid-cache.org[12.160.37.9]
> ...
> Sep 24 07:52:07 barattolo postfix/cleanup[5848]: warning: 2928F10000E: read
> timeout on cleanup socket
> ...
> Sep 24 08:01:48 barattolo postfix/smtpd[5832]: disconnect from
> squid-cache.org[12.160.37.9]
Wietse
