On Monday 29 June 2009 19:44:49 Steve wrote: > Alan McKinnon wrote: > > Looks like you have 200 processes sitting there blocking I/O. Is there > > anything related in the logs? > > Not sure - as I'm not sure where to look, or what to look for. > > > Your best bet is to examine emerge.log (better still - genlop) and find > > all recent upgrades that might affect this. Then roll them back one by > > one till the problem goes away. Once you know the errant package, we can > > start to examine diffs and see why it might behave like that. > > The only relevant package seems to be clamav... my emerge.log shows that > I upgraded 8 packages yesterday just before 5pm - and the second of > these was app-antivirus/clamav-0.95.2 - I think I simply chose to use > the new configurations after issuing a dispatch-config... I didn't do > anything 'adventurous'. > > Perhaps this might be something to do with a long-forgotten hack for > clamassassin to work with clamd that might have been overwritten... > (changing CLAMSCAN=/usr/bin/clamscan to CLAMSCAN=/usr/bin/clamdscan in > /usr/bin/clamassassin) but this seems odd - since the date on > clamassassin is 7 September 2008... and this problem with my server is > very recent - it was working fine yesterday... and clamassassin hasn't > been re-installed since everything worked fine - only clamav was emerged. > > As an interim hack, I've removed /usr/bin/clamassassin from my global > procmailrc; stopped spamd; killed all the procmail and clamscan > processes - and restarted postfix. This has left me with an operational > server with which I can interact. It would seem very strange if I'm the > only person having trouble with clamscan... in the context of what (I > think) is a fairly standard postfix install.
That looks sane enough. I guess now you get to keep an eye on it for a few days. -- alan dot mckinnon at gmail dot com
