On Thu, Feb 05, 2004 at 07:12:23PM +0700, Frank Rabitsch wrote: ...
> Difficult to match the failing messages on the sending side with log entries > on the receiving side. Let me give it a try... > > This is how a normal session should look like according to me: > > 2004-02-03 20:01:07.186652500 tcpserver: pid 23973 from 10.2.0.1 > 2004-02-03 20:01:07.189260500 tcpserver: ok 23973 > mail.ph.magnusint.com:10.2.0.7:628 :10.2.0.1::59579 > 2004-02-03 20:01:07.196407500 ok 1075813267 qp 23974 ddc saved 43 percent > 2004-02-03 20:01:07.196737500 tcpserver: end 23973 status 0 > > It starts up the connection then tcpserver reports OK, and the pid is ended > in the 4th line. This logentry is from a null client on the firewall on the > same subnet so on a fast network connection. On the 3rd line it reports ok > but I don't know how to match the number 23974 to the original message pid > 23973. If the session is fast its most likely one number higher but on slow > sessions the number is not sequential. > > The following entries are of a failing session: > > 2004-02-03 18:37:15.950854500 tcpserver: pid 23576 from 10.1.0.7 > 2004-02-03 18:37:15.952341500 tcpserver: ok 23576 > mail.ph.magnusint.com:10.2.0.7:628 :10.1.0.7::32940 > ... > 2004-02-03 19:37:15.943964500 tcpserver: end 23576 status 28416 > > As you can see there is one hour delay and the status code is 28416. Don't > know what this code means. > status is the exit status. This is what wait(2) returns for the process. In this case it is an _exit(3) code of 111. This is definitifly the 1h alarm timer that went off. > If I do a flush on the sending side it starts up ten delivries at once. Some > of them return with the "communication_with_mail_server_failed" message. On > the receiving side I see that some of them end with status 28416 as above. > Some of them simply end with status 0 however I don't get an OK messages on > the receiving side (e.g. ...ok 1075813267 qp 23974 ddc saved 43 percent) for > all of the ending connections with status 0. > > Let me know what could be the cause of this problem or how I should analyze > the log-files. Thanks. > Hmm. I will try to find out why qmail-qmqpd blocks after printing the OK line. Seems very strange. -- :wq Claudio
