On Mon, Sep 15, 2014 at 04:54:11AM +0000, Viktor Dukhovni wrote: > * Your DNS resolution is not functioning, which could also > explain slow login, but in this case, you'd generally max > out the smtpd(8) process limit.
Yes, this one occurred to me too, but I did test that specifically, and it doesn't seem to be the issue. The systems have local unbound and rbldnsd instances running, and name resolution appears to be functioning quickly on the system. There is also an LDAP dependency, but I think there would be something logged if the problem were LDAP related, and I don't see evidence that that's the case. > You need to determine which smtpd(8) process (if any) is blocked > in accept(2) while all rest are blocked trying to obtain a lock. > > You need to determine which cleanup(8) process (if any) is blocked > in accept(2) while all rest are blocked trying to obtain a lock. In terms of your other suggestions, what should I look at? FWIW, I have the saved netstat output, and I see: unix 2 [ ACC ] STREAM LISTENING 21192 public/cleanup unix 3 [ ] STREAM CONNECTED 7527374 public/cleanup unix 3 [ ] STREAM CONNECTED 7527010 public/cleanup unix 3 [ ] STREAM CONNECTED 7526233 public/cleanup I don't see any smtpd processes with ACC in the same list, so this would suggest that cleanup is the problem? FWIW, the process output from the same time shows 2 cleanup processes: postfix 30177 7244 0 19:50 ? 00:00:00 cleanup -z -t unix -u postfix 30178 7244 0 19:50 ? 00:00:00 cleanup -z -t unix -u postfix 30314 7244 0 19:51 ? 00:00:00 cleanup -z -t unix -u all well after the problem started coming up; I assume these correspond to the bottom 3 cleanup processes in the netstat output. Thanks for the quick and helpful response. w
