Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[AMaViS-user] Clamav problems

1 view
Skip to first unread message

Danita Zanre

unread,
Jun 5, 2008, 9:25:22 PM6/5/08
to
Okay - first off let me assure everyone that I didn't DO anything :)

I have noticed that about once every 3 or 4 months I have problems with
amavisd looking like it has just "gone to sleep". The processes all
either stick at one pass, or say "virgin child" and nothing seems to
kick them, and then suddenly, they will clear up as quickly as they got
stuck (typically hours later after trying to restart things over and
over, etc.).

Today I seem to have narrowed it down to clamav, and if I remove the
clam commands from amavisd.conf things are "back to normal" but of
course not really.

I've tried using clamd-socket, port 3310 and both fail. The user is
"vscan" which is the same user that amavis uses, and this has been
working for YEARS.

clamd loads, but doesn't seem to create a pid that I can see - it
should be in /var/lib/clamav - not there. I've checked and the
permissions for the directory are correct (as I say, it just stopped
working in the middle of the day).

Where can I look?

Thanks.

Danita

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
AMaViS-user mailing list
AMaVi...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Andrew Ho

unread,
Jun 6, 2008, 11:08:22 AM6/6/08
to
It is probably the clamd.sock is not located in the same directory.

Check these two files again, and you may be find out the errors, and the
init files in /etc/init.d.


Andrew

Danita Zanre

unread,
Jun 6, 2008, 11:23:30 AM6/6/08
to
>>> On Friday, June 06, 2008 at 9:08 AM, in message
<484952E6...@animezone.org>, Andrew Ho <andr...@animezone.org>
wrote:
> It is probably the clamd.sock is not located in the same directory.
>
> Check these two files again, and you may be find out the errors, and
the
> init files in /etc/init.d.

The clamd.conf file says that the pid and clamd-socket files are
supposed to be in /var/lib/clamav. The databases definitely are there,
but I see no pid - that said, just as quickly as it broke, it seems to
have fixed itself using port 3310 (invisible pid notwithstanding). But
that didn't fix the amavis processes just wanting to nap. By the time
it was done I ended up with more than 1000 messages in my mail queue to
be processed, and somehow they started processing again just to spite me
more than anything I think!

My biggest issue with these "lazy amavis processes" as I've come to
call them, is that I can never seem to find a common solution that will
fix it each time, and also because it's generally so far between
incidents (I've had it happen about 5 times in the 3 or so years I've
used this setup) that when it happens I start pulling my hair out. And
then it almost seems like as suddenly as the problem occurs, it goes
away. I really have no idea if the clamav issue had anything at all to
do with the bigger problem, but it did eventually all get sorted out.

Mark Martinec

unread,
Jun 17, 2008, 3:18:31 PM6/17/08
to
Danita,

> My biggest issue with these "lazy amavis processes" as I've come to
> call them, is that I can never seem to find a common solution that will
> fix it each time, and also because it's generally so far between
> incidents (I've had it happen about 5 times in the 3 or so years I've
> used this setup) that when it happens I start pulling my hair out. And
> then it almost seems like as suddenly as the problem occurs, it goes
> away. I really have no idea if the clamav issue had anything at all to
> do with the bigger problem, but it did eventually all get sorted out.

To investigate such mystery cases, it pays off to keep a debug log
for the last few days, then throw it away automaticaly. Syslog allows
to have multiple logs at different syslog priorities, so I keep one
essential amavisd log collected at user.notice level for the archival
purposes, and I have a second throw-away log at user.debug level
for forensic purposes. (actually I also have an intermediate log
to be able to analyse timing reports)

/etc/syslog.conf:

user.notice /var/log/amavisd.log
user.info /var/log/amavisd-info.log
user.debug /var/log/amavisd-debug.log

amavisd.conf:

$log_level = 5; # verbosity 0..5
$DO_SYSLOG = 1; # log via syslogd
$syslog_facility = 'user';
$syslog_priority = 'debug';


Mark

0 new messages