On 11/20/2014 01:12 PM, Tom Kinghorn wrote: > On 2014/11/20, 12:22 PM, Nigel Kukard wrote: >> >> Ok, everything looks pretty idle to me. Thats a good thing. First >> thing I do is look for CPU usage (shows you how much power your rules >> need) and then DB usage (how many queries required to satisfy the >> policies you have in place). All yours look good. >> >> 1. Can you try enable full debugging and see if you see anything odd? >> I'd expect a bunch of children to start up. >> >> 2. Also, try disable all your policies and see if you still have a >> problem. I'm thinking maybe DNS resolution may be taking some time if >> you using say the HELO check? Disabling all policies will show you if >> policyd can process the requests its getting. >> >> We'll take it from there then. >> >> -N > Hi Nigel. > > Apparently a new DNS cluster has been provisioned and the servers > which were alocated to me were still set to the old > dns servers, which would have slowed down the DNS resolution. > > I have updated resolv.conf to reflect the new DNS cluster....lets see > what happens > > I have noted a difference in the logs. > No connection refused now...just lots of > > Nov 20 15:09:11 smtp7 postfix/smtpd[15708]: warning: problem talking > to server 10.113.157.19:10031: Connection timed out > Nov 20 15:09:17 smtp7 postfix/smtpd[14146]: warning: problem talking > to server 10.113.157.19:10031: Connection timed out
Try capture one of the policy requests using tcpdump or even using a custom one, then feed it via netcat/socat/nc6 into policyd. May very well be DNS especially if you use any DNS checks in policyd. I'd say look there first ;) then move onto submitting it yourself and trying to see if you can reproduce manually. -N
_______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
