Description of problem: amavisd fails to use clamd because of group permissions in /var/lib/clamav it is recomanded to run clamd as User clamav and add the user to group amavisd However, /var/lib/clamav has group read only, but need write for amavisd As a result amavisd fails using clamd and uses a backup scanner such as clamscan. This makes the process unusable slow and oftehn times out leaving the mail in the deferred state Version-Release number of selected component (if applicable): 0.98.1-1.mga4 How reproducible: every time Steps to Reproduce: 1. setup the mail system using amavisd and clamd for virus 2. send/receive mail 3. use systemctl status amavisd 4. it reports that all primary scanners fail, using backup Reproducible: Steps to Reproduce:
Status: NEW => ASSIGNED
Assignee: bugsquad => thomas
This bug has now been resolved. I tested it and got these results: Before upgrade: Mar 10 12:02:10 vbox.btspuhler.com amavis[4659]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan Mar 10 12:02:11 vbox.btspuhler.com amavis[4659]: Deleting db files in /var/run/amavis/db Mar 10 12:02:11 vbox.btspuhler.com amavis[4659]: Creating db in /var/run/amavis/db/; BerkeleyDB 0.53, libdb 5.3 Mar 10 12:02:36 vbox.btspuhler.com amavis[4676]: (04676-01) (!)connect to /var/lib/clamav/clamd.socket failed, attempt #1: Can't c...refused Mar 10 12:02:37 vbox.btspuhler.com amavis[4676]: (04676-01) (!)connect to /var/lib/clamav/clamd.socket failed, attempt #1: Can't c...refused Mar 10 12:02:37 vbox.btspuhler.com amavis[4676]: (04676-01) (!)ClamAV-clamd: All attempts (1) failed connecting to /var/lib/clamav...ing (2) Mar 10 12:02:43 vbox.btspuhler.com amavis[4676]: (04676-01) (!)connect to /var/lib/clamav/clamd.socket failed, attempt #1: Can't c...refused Mar 10 12:02:43 vbox.btspuhler.com amavis[4676]: (04676-01) (!)ClamAV-clamd av-scanner FAILED: run_av error: Too many retries to t... 600.\n Mar 10 12:02:43 vbox.btspuhler.com amavis[4676]: (04676-01) (!)WARN: all primary virus scanners failed, considering backups Mar 10 12:02:58 vbox.btspuhler.com amavis[4676]: (04676-01) Passed CLEAN {RelayedInbound}, <root@vbox.btspuhler.com> -> <thomas.sp. after upgrade: Mar 10 14:32:35 vbox.btspuhler.com amavis[18935]: Found decoder for .exe at /usr/bin/lha Mar 10 14:32:35 vbox.btspuhler.com amavis[18935]: No decoder for .F Mar 10 14:32:35 vbox.btspuhler.com amavis[18935]: No decoder for .lrz Mar 10 14:32:35 vbox.btspuhler.com amavis[18935]: No decoder for .zoo Mar 10 14:32:35 vbox.btspuhler.com amavis[18935]: Using primary internal av scanner code for ClamAV-clamd Mar 10 14:32:35 vbox.btspuhler.com systemd[1]: Started AMAVIS interface between MTA and content checkers. Mar 10 14:32:35 vbox.btspuhler.com amavis[18935]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan Mar 10 14:32:35 vbox.btspuhler.com amavis[18935]: Deleting db files nanny.db,snmp.db,__db.003,__db.002,__db.001 in /var/run/amavis/db Mar 10 14:32:35 vbox.btspuhler.com amavis[18935]: Creating db in /var/run/amavis/db/; BerkeleyDB 0.53, libdb 5.3 Mar 10 14:45:04 vbox.btspuhler.com amavis[18944]: (18944-01) Passed CLEAN {RelayedInbound}, <root@vbox.btspuhler.com> -> <thomas.sp...197 ms The updated packages are in upgrade_testing: clamav-0.98.1-1.1.mga4.i586.rpm clamav-db-0.98.1-1.1.mga4.noarch.rpm clamav-milter-0.98.1-1.1.mga4.i586.rpm clamd-0.98.1-1.1.mga4.i586.rpm libclamav-devel-0.98.1-1.1.mga4.i586.rpm libclamav6-0.98.1-1.1.mga4.i586.rpm and the corresponding x64
CC: (none) => thomas
Assignee: thomas => qa-bugs
assgining it to QA
Tried absolutely minimally MGA4 64-bit real hardware. Installed from Release the 5 pkgs cited in Comment 1 (excluding devel), plus amavisd and necessarily Postfix. Rebooted, no visible problems - but nothing was actually *done*. Updated with no problems from Updates Testing the 5 pkgs cited in Comment 1 (excluding devel). Rebooted, and trying both freshclam and clamscan repeatedly threw up problems about permissions on a couple of /var directories, even after re-booting. Call it a mystery BECAUSE re-trying the next day, these both worked OK; clamscan found the eicar test file. The only puzzle for me was that clamav-milter service was not started, nor (using MCC) could it be. Tried with 2 kernels: normal desktop, and rt. Same behaviour. This was true both before & after the update, so is not due to it. In the absence of more expert appraisal, or advice as to something else to look for - OK.
CC: (none) => lewyssmithWhiteboard: (none) => MGA4-64-OK
I kind of remember, to use clamav-milter, you have to stop the another version. But I worked on this loooong ago.
FWIW, I found a few problems with the systemd units in both cauldron and this backported package. I've taken the liberty of fixing them and killing off the (non-functioning) support for the /etc/sysconfig/* files related to this package (they were included in the systemd units but the variables the defined were not used in the ExecStart line). The major problem with this (and the previous MGA4 version) is that freshclam did not run as a daemon as intended. It ran once at boot and then stayed off. I've only just noticed that my freshclam on one server has not run in over a month. Updated packages should fix the issue SRPM clamav-0.98.3-1.1.mga4.src.rpm i586 clamav-0.98.3-1.1.mga4.i586.rpm clamav-db-0.98.3-1.1.mga4.noarch.rpm clamav-milter-0.98.3-1.1.mga4.i586.rpm clamd-0.98.3-1.1.mga4.i586.rpm libclamav6-0.98.3-1.1.mga4.i586.rpm libclamav-devel-0.98.3-1.1.mga4.i586.rpm x86_64 clamav-0.98.3-1.1.mga4.x86_64.rpm clamav-db-0.98.3-1.1.mga4.noarch.rpm clamav-milter-0.98.3-1.1.mga4.x86_64.rpm clamd-0.98.3-1.1.mga4.x86_64.rpm lib64clamav6-0.98.3-1.1.mga4.x86_64.rpm lib64clamav-devel-0.98.3-1.1.mga4.x86_64.rpm NB, the version bump was done by Thomas earlier before his comment #2 but not mentioned, so I suspect you used the 0.98.3 version Lewis as opposed to 0.98.1?
CC: (none) => mageia
Ooops, read my dates wrong, Thomas bumped the version and submitted to updates testing *after* comment #2 but *before* Lewis' testing in comment #3 (I think!). Sorry!
Testing ultra-minimally again MGA4 64-bit real hardware. Taking note of Comment 5 (re Comment 3): I was indeed trying version 0.98.1-1.1.mga4 of programs ex Comment 1. Updated again to clamav-db-0.98.3-1.1.mga4 clamav-0.98.3-1.1.mga4 clamav-milter-0.98.3-1.1.mga4 lib64clamav6-0.98.3-1.1.mga4 re-started the system. - clamd is running. - clamav-milter is suspended, and will not start. What is it? - Using clamscan command took a long time to get going, but worked & found eicar. - freshclam *is* running as a service: # systemctl -l status freshclam freshclam.service - Clam AntiVirus Daemon is a TCP/IP or unix domain Loaded: loaded (/usr/lib/systemd/system/freshclam.service; enabled) Active: active (running) since Mer 2014-05-14 21:10:28 CEST; 1h 31min ago # systemctl -l status amavisd amavisd.service - AMAVIS interface between MTA and content checkers Loaded: loaded (/usr/lib/systemd/system/amavisd.service; enabled) Active: active (running) since Mer 2014-05-14 21:10:33 CEST; 1h 16min ago ... 21:10:33 localhost amavis[2472]: Found decoder for .rar at /usr/bin/7z 21:10:33 localhost amavis[2472]: Found decoder for .swf at /usr/bin/7z 21:10:33 localhost amavis[2472]: Found decoder for .lha at /usr/bin/7z 21:10:33 localhost amavis[2472]: Found decoder for .iso at /usr/bin/7z 21:10:33 localhost amavis[2472]: Found decoder for .exe at /usr/bin/lha; /usr/bin/arj 21:10:33 localhost amavis[2472]: No decoder for .lrz 21:10:33 localhost amavis[2472]: No decoder for .zoo 21:10:33 localhost amavis[2472]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan 21:10:33 localhost amavis[2472]: Deleting db files in /var/run/amavis/db 21:10:33 localhost amavis[2472]: Creating db in /var/run/amavis/db/; BerkeleyDB 0.53, libdb 5.3 Re Description/Comment0 $ ls -l /var/lib drwxrwxr-x 3 clamav clamav 4096 Mai 14 22:11 clamav/ $ cat /etc/group amavis:x:471:clamav Does all this help?
Ahh yes Lewis, there is a (rather obvious now it's been seen) typo in the package that caused the milter unit to be the same as the clamd unit (wrong %SOURCEn), so they were both trying to start the same thing and failing. Have tested that milter starts now, but not more than that (e.g. not checked to see how/if it actually works!) The units might need some more deps (e.g. perhaps milter needs to be started before sendmail/postfix (the fedora unit does - but I'll leave that one to Thomas). clamscan also takes a while for me (9s) but running it through strace seems to suggest it's workign that whole time. I guess it's not talking to clamd here. clamdscan works way faster, provided the clamav user can read the file in question. The 9s overhead seems to tally with the delay in starting clamd itself (for me), so I guess this all fits in OK - it's just "reading the virus db". Anyway, updated packages submitted. 0.9.3-1.2.mga4.
Reference for the version update: http://www.clamav.net/lang/en/2014/05/07/clamav-0-98-3-has-been-released/ BTW, it appears the Mageia 3 update is missing in this bug. Someone just requested it in Bug 13417. It looks like Thomas has 0.98.3 in Mageia 3 SVN. Colin, since Thomas is on vacation, would you mind making any needed fixes in the Mageia 3 branch and pushing that as well?
Blocks: (none) => 13417
Colin/Thomas, could you comment on David's comment 9 please.
Whiteboard: MGA4-64-OK => feedback MGA4-64-OK
(In reply to David Walser from comment #9) > Reference for the version update: > http://www.clamav.net/lang/en/2014/05/07/clamav-0-98-3-has-been-released/ > > BTW, it appears the Mageia 3 update is missing in this bug. Someone just > requested it in Bug 13417. > > It looks like Thomas has 0.98.3 in Mageia 3 SVN. > > Colin, since Thomas is on vacation, would you mind making any needed fixes > in the Mageia 3 branch and pushing that as well? This update has been in testing for a while and 0.98.3 has been released in the meantime. So it's fine to release both, mga3 and mga4. I can make the permission change in mga3, Bug 13417 after the release of 0.98.3. I'll be back home next week. Thomas
(In reply to Colin Guthrie from comment #8) > Ahh yes Lewis, there is a (rather obvious now it's been seen) typo in the > package that caused the milter unit to be the same as the clamd unit (wrong > %SOURCEn), so they were both trying to start the same thing and failing. > > Have tested that milter starts now, but not more than that (e.g. not checked > to see how/if it actually works!) > > The units might need some more deps (e.g. perhaps milter needs to be started > before sendmail/postfix (the fedora unit does - but I'll leave that one to > Thomas). > > clamscan also takes a while for me (9s) yes, it will take very long if using clamscan. It will take this long for every e-mail as clamscan will start again for every e-mail. This is why clamd needs to work. Otherwise, e-mail on a busy server will just pile up. >but running it through strace seems > to suggest it's workign that whole time. I guess it's not talking to clamd > here. clamdscan works way faster, provided the clamav user can read the file > in question. The 9s overhead seems to tally with the delay in starting clamd > itself (for me), so I guess this all fits in OK - it's just "reading the > virus db". > > Anyway, updated packages submitted. 0.9.3-1.2.mga4.
The clamd bug has been fixed and the pacakges also upddated to the latest upstream release. The following packages are now in updates_testing: clamav-0.98.3-1.2.mga4.src.rpm clamav-db-0.98.3-1.2.mga4.noarch.rpm clamav-0.98.3-1.2.mga4.x86_64.rpm clamav-debuginfo-0.98.3-1.2.mga4.x86_64.rpm clamav-milter-0.98.3-1.2.mga4.x86_64.rpm clamd-0.98.3-1.2.mga4.x86_64.rpm lib64clamav-devel-0.98.3-1.2.mga4.x86_64.rpm lib64clamav6-0.98.3-1.2.mga4.x86_64.rpm In order to test it, you need to activate the clamd scanner in the primary scanner section of /etc/amavisd.conf by uncommenting the relevant lines. Ifter restarting amavisd ans sending a test e-mail, the output should like this: # systemctl -l status amavisd amavisd.service - AMAVIS interface between MTA and content checkers Loaded: loaded (/usr/lib/systemd/system/amavisd.service; enabled) Active: active (running) since Wed 2014-06-04 09:11:06 MST; 11min ago Process: 6874 ExecStart=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf -P /run/amavis/amavis.pid (code=exited, status=0/SUCCESS) Main PID: 6879 (/usr/sbin/amavi) CGroup: /system.slice/amavisd.service ââ6879 /usr/sbin/amavisd (master ââ6888 /usr/sbin/amavisd (ch2-avail ââ6889 /usr/sbin/amavisd (ch1-avail Jun 04 09:11:06 vbox.btspuhler.com amavis[6879]: No decoder for .zoo Jun 04 09:11:06 vbox.btspuhler.com amavis[6879]: Using primary internal av scanner code for ClamAV-clamd Jun 04 09:11:06 vbox.btspuhler.com amavis[6879]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan Jun 04 09:11:07 vbox.btspuhler.com amavis[6879]: Deleting db files nanny.db,snmp.db,__db.003,__db.002,__db.001 in /var/run/amavis/db Jun 04 09:11:07 vbox.btspuhler.com amavis[6879]: Creating db in /var/run/amavis/db/; BerkeleyDB 0.53, libdb 5.3 Jun 04 09:15:44 vbox.btspuhler.com amavis[6888]: (06888-01) Passed CLEAN {RelayedInbound},......... Look for this line: Using primary internal av scanner code for ClamAV-clamd For the updates of clamav, use the standard procedures
Advisory: This bug updates fixes the problem of not being able to run clamd as User Clamav Updated packages in core/updates_testing: clamav-0.98.4-1.mga4.src.rpm clamav-0.98.4-1.mga4.i586.rpm clamav-db-0.98.4-1.mga4.noarch.rpm clamav-milter-0.98.4-1.mga4.i586.rpm clamd-0.98.4-1.mga4.i586.rpm libclamav-devel-0.98.4-1.mga4.i586.rpm libclamav6-0.98.4-1.mga4.i586.rpm and relevant 64bit rpms See also bug 13417 for updating clamav
CC: (none) => qa-bugsAssignee: qa-bugs => thomasWhiteboard: feedback MGA4-64-OK => (none)
resolve of bug #13417 fixed this one too. Let's close it as resolved
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED