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.
