On Fri, Jul 10, 2009 at 08:50:29AM -0400, Wietse Venema wrote:
> Jakub Nadolny:
> > > One SMTP client process was delivering message DF7C21811E53, and
> > > that process hangs.
> > > 
> > >     THIS IS WHY YOU SEE THE 'DF7C21811E53: SKIPPED,
> > >     STILL BEING DELIVERED' MESSAGE IN THE LOGFILE.
> > > 
> > > Normally, a watchdog timer will terminate such a process, and the
> > > master will log a warning when that happens.  The time limit is
> > > specified with (main.cf:daemon_timeout, and is 1800s or five hours.
> > 
> > Thank you again. After 4.5 hour message was at last delivered. I would like 
> > to
> > know for the future (as such cases are not so rare):
> 
> 4.5 hours for a 4254293-byte message, that's 260 bytes/second.
> This can happen with a slow connection, and with a connection that
> is manipulated by a traffic shaping system.
> 
> > 1. What can I do if again SMTP client process will hang? 
> 
> Given that the mail arrived after several hours, it seems that the
> warning message "still being delivered" was correct, and that the
> process was in fact not hanging.
> 
> You can use any number of process inspection tools to see where
> a process is. Some examples are: 
> 
>       # strace -p pid
>       ...
>       ^C
>       # gdb /path/to/smtp pid
>       (gdb) where
>       ...
>       (gdb) detach
> 
> > 3. Does it have connection with Send-Q > 80000 as displayed in netstat as I
> > mentioned before?
> 
> You are sending a megabyte file, and some portion of that will be
> in the local TCP send queue. If the receiving side reads your data
> very slowly, then Postfix network write operations will never time
> out, but they will take more time than usual.
> 
> You can check this with tcpdump. The symptoms are a relatively
> small TCP window size and a low packet rate. Slow data rates are
> a feature of traffic-shaping tools that can be installed in front
> of a receiving MTA. Of course slow data rates can also have other
> causes.
> 
>       tcpdump host xx and port yy
> 
> Postfix is happy as long as it can send a non-zero number of bytes
> every $smtp_data_xfer_timeout seconds (180s by default). This limits
> the theoretical data rate to 1/180 byte/s. In practice the watchdog
> timer will kill the SMTP client.

Thanks a lot! That are great tips to be used. I wish every software has such a
good author support as yours.

Best Regards,
Jakub

Reply via email to