Hello John, > Upgrading one package from CPAN _shouldn't_ be _that_ intrusive. > Telling > it to upgrade everthing is probably a bad idea, though.
I think that last time we used CPAN, I went to upgrade just one package, and it caught the fact that I would be missing dependencies. It then went about automatically upgrading all the packages we apparently needed to support the Perl module I was upgrading. I understand this behaviour can be switched off, but I'm in no hurry to touch CPAN again thanks :) > > I don't see where Net::DNS is causing an issue, however.. > > It probably is not, but I don't pay a great deal of attention > discussion > of problems in it, so I'm not sure. Upgrading it shouldn't hurt and may > help. > > > Is there some debug routine I can throw in to get a general idea of > how > > it is performing for all E-Mail? > > "it" being DNS? Yes, "-D dns" as you've done, or the more verbose "-- > debug > area=dns". You can also run "--debug area=dns,all" to see everything > else > too. And with -D I discovered: Apr 8 22:41:08 tuatara spamd[1291]: dns: timeout for zen-lastexternal,zen,zen-lastexternal after 4 seconds Apr 8 22:41:09 tuatara spamd[1292]: dns: timeout for sorbs-lastexternal,sorbs after 7 seconds Apr 8 22:41:09 tuatara spamd[1292]: dns: timeout for zen-lastexternal,zen,zen-lastexternal after 7 seconds Apr 8 22:41:16 tuatara spamd[1921]: dns: timeout for zen after 5 seconds Apr 8 22:41:16 tuatara spamd[1921]: dns: timeout for zen-lastexternal,zen,zen-lastexternal after 5 seconds Apr 8 22:41:18 tuatara spamd[1291]: dns: timeout for sorbs-lastexternal,sorbs after 7 seconds I have managed to replicate this from the command line, so this probably isn't a spamassassin issue anymore. So, I've found the problem, or at least part of it. We're going to run analysis of this via NetPriva and get some more logging happening with Bind (also running on the mail server), and I will enable --debug area=dns at your suggestion to see if we can pin this issue for good. > > If I am correct, this server hasn't used any swap for quite some > time, > > but does keep the physical memory well consumed for performance > reasons. > > (Debian 3.1 Sarge). > > That looks good. > > These are superficial suggestions, of course. They all help, John. Thanks for your response and ideas! :) Cheers, Michael Hutchinson
