clamscan timed out
發表於 : 2008-04-12 01:08:09
from http://marc.info/?l=postfix-users&m=119852130019268
> Gary V wrote:
> > > Damien Hull wrote:
> > > > It works!
> > > > Turns out it was user error on my part. I forgot to add the clamav user
> > > > to the amavis group ;-) . I guess I need to go back and edit my
> > > > documentation.
> > > Right, this is documented in the INSTALL document of amavisd.
> > >
> > > > "Package clamav-0.92-1 has the following notes (see clamav.spec for details)
> > > > o amavisd-new requires clamd to run as user vscan, solution needed"
> > > There were some reports that setting "AllowSupplementaryGroups yes"
> > > in clamd.conf (and following the above advice of adding user clamav
> > > to the amavis/vscan group) does not work on some Linux distributions,
> > > perhaps starting with certain version of clamd. Unfortunately none
> > > of the reporters were able or willing to track down the source
> > > of the problem - and on other installations it runs just fine.
> > > So, either some Linux distros broke the initgroups(3), or it
> > > may just be some common operator error. The above claim that
> > > 'amavisd-new requires clamd to run as user vscan' should be
> > > viewed in this context.
> > >
> > > Mark
> >
> > I believe the symptoms to the issue you are referring to were misleading. On the \
> > surface it appeared to be a permissions problem, but could have been the fact \
> > that some 0.90.x versions of clamd would take *several minutes* to load the \
> > definitions database, and as a result, the clamd socket would not get created \
> > until that process completed. It was a matter of being patient enough to wait for \
> > creation of the socket.
>
> Hello... I'm facing some problems related with ClamAV and its socket
> file not being created so fast after every restart.
>
> This message is the very first one I found not trying to explain this
> problem using any argument related with permissions and so. My system is
> running Debian Etch, Postfix 2.3.8 and ClamAV 0.90.1.
>
> My "solution" to this problem was to pause Postfix queue and wait until
> ClamAV stop consuming "system resource" (I have no idea what was going
> on, the only symptom I could see was a very high system load during a
> quite long time).
>
> Let's investigate something more about loading database definitions and
> more...
>
> Greetings.
> --
> Miguel Da Silva
No need to, this was resolved in newer versions. You simply need to upgrade your \
version of ClamAV.
For Debian I suggest adding etch volatile source to /etc/apt/sources.list
deb http://volatile.debian.org/debian-volatile etch/volatile main
Then:
gpg --keyserver subkeys.pgp.net --recv-key BBE55AB3
gpg --armor --export BBE55AB3 | apt-key add -
apt-get update
apt-get install clamav clamav-daemon clamav-freshclam
At least, this is how I would do it. YMMV. No guarantees.
This subject is off topic.
> Gary V wrote:
> > > Damien Hull wrote:
> > > > It works!
> > > > Turns out it was user error on my part. I forgot to add the clamav user
> > > > to the amavis group ;-) . I guess I need to go back and edit my
> > > > documentation.
> > > Right, this is documented in the INSTALL document of amavisd.
> > >
> > > > "Package clamav-0.92-1 has the following notes (see clamav.spec for details)
> > > > o amavisd-new requires clamd to run as user vscan, solution needed"
> > > There were some reports that setting "AllowSupplementaryGroups yes"
> > > in clamd.conf (and following the above advice of adding user clamav
> > > to the amavis/vscan group) does not work on some Linux distributions,
> > > perhaps starting with certain version of clamd. Unfortunately none
> > > of the reporters were able or willing to track down the source
> > > of the problem - and on other installations it runs just fine.
> > > So, either some Linux distros broke the initgroups(3), or it
> > > may just be some common operator error. The above claim that
> > > 'amavisd-new requires clamd to run as user vscan' should be
> > > viewed in this context.
> > >
> > > Mark
> >
> > I believe the symptoms to the issue you are referring to were misleading. On the \
> > surface it appeared to be a permissions problem, but could have been the fact \
> > that some 0.90.x versions of clamd would take *several minutes* to load the \
> > definitions database, and as a result, the clamd socket would not get created \
> > until that process completed. It was a matter of being patient enough to wait for \
> > creation of the socket.
>
> Hello... I'm facing some problems related with ClamAV and its socket
> file not being created so fast after every restart.
>
> This message is the very first one I found not trying to explain this
> problem using any argument related with permissions and so. My system is
> running Debian Etch, Postfix 2.3.8 and ClamAV 0.90.1.
>
> My "solution" to this problem was to pause Postfix queue and wait until
> ClamAV stop consuming "system resource" (I have no idea what was going
> on, the only symptom I could see was a very high system load during a
> quite long time).
>
> Let's investigate something more about loading database definitions and
> more...
>
> Greetings.
> --
> Miguel Da Silva
No need to, this was resolved in newer versions. You simply need to upgrade your \
version of ClamAV.
For Debian I suggest adding etch volatile source to /etc/apt/sources.list
deb http://volatile.debian.org/debian-volatile etch/volatile main
Then:
gpg --keyserver subkeys.pgp.net --recv-key BBE55AB3
gpg --armor --export BBE55AB3 | apt-key add -
apt-get update
apt-get install clamav clamav-daemon clamav-freshclam
At least, this is how I would do it. YMMV. No guarantees.
This subject is off topic.