Description of problem: The clamonacc.service fails to start and outputs these messages: Dec 18 12:05:17 <redacted> systemd[1]: Started ClamAV On-Access Scanner. Dec 18 12:05:17 <redacted> clamonacc[9209]: ERROR: Clamonacc: Version of curl is too low to use fdpassing. Please use tcp socket streaming instead Dec 18 12:05:17 <redacted> clamonacc[9209]: . Dec 18 12:05:17 <redacted> systemd[1]: clamav-clamonacc.service: main process exited, code=exited, status=2/INVALIDARGUMENT Dec 18 12:05:17 <redacted> systemd[1]: Unit clamav-clamonacc.service entered failed state. Dec 18 12:05:17 <redacted> systemd[1]: clamav-clamonacc.service failed. Version-Release number of selected component (if applicable): clamav-0.103.0-1.el7.x86_64 How reproducible: It is always reproducible. Steps to Reproduce: 1. # yum install clamav clamd 2. # systemctl start clamonacc Actual results: clamonacc service fails to start Expected results: clamonacc starts and is able to detect malware Additional info: The clamonacc service worked in clamav-0.102.4-1.el7.x86_64
Hello and Happy December! We are encountering the same issue here on RHEL-7. We are unable to upgrade to v103 at this time -- I've tried to rebuild the clamav rpm from the src.rpm but the build time dependencies seem to be unsatsifiable on RHEL7 (e.g. groff and json-c-devel packages are nonexistent on RHEL-7). Please let me know if there's any debugging output or logging that I can provide to help bring this to resolution Cheers, Seemant, on behalf of Issio Solutions
Please note, we are using curl-7.73/7.74 off the city-fan archive, so I want to confirm that the curl version in use is, in fact, high enough on our systems here.
from https://bugzilla.redhat.com/show_bug.cgi?id=1901676 after read https://github.com/Cisco-Talos/clamav-devel/commit/29389cb7745bc46a6054b0cb3564e36635a73abc seems we can drop clamav-curl.patch the patch was https://src.fedoraproject.org/rpms/clamav/blob/e76df38561125e90a4f7aa2cecce5248bbc9a5c1/f/clamav-curl.patch the message is "Please use tcp socket streaming instead" , I don't know what it means suggestions ?
to clamav-clamonacc.service start on epel7 you need set TCPSocket and TCPAddr for example: TCPSocket 3310 TCPAddr 127.0.0.1
Thank you for this workaround, Sergio. Here's hoping the rpm itself gets fixed soon, so we can resume `clamonacc --fdpass`
(In reply to seemant from comment #5) > Thank you for this workaround, Sergio. > Here's hoping the rpm itself gets fixed soon, so we can resume `clamonacc > --fdpass` In EL7, as the solution is , `clamonacc --fdpass` will not be allowed [1] , what we can do is change the default clamonacc configuration for EL7 . [1] ERROR: Clamonacc: Version of curl is too low to use fdpassing. Please use tcp socket streaming instead
The issue with libcurl also existed in clamav 0.102 and it was fixed in version 0.102.2-7 (bz#1820395) by statically linking against a newer libcurl version. Is there any reason why this patch was dropped for 0.103?
because https://github.com/Cisco-Talos/clamav-devel/commit/29389cb7745bc46a6054b0cb3564e36635a73abc but if we can do better let me know . Please read comment #3
compiling clamav-devel from 0.103 using cmake produces a working clamonacc of 160k size. the epel/self-packaged 0.103 will produce a clamonacc of 8k size, that will fail upon any file access as reported here: https://bugzilla.clamav.net/show_bug.cgi?id=12650
1. Building ClamAV with CMake CLamAV versions 0.103+ provide CMake build tooling. In 0.103, this is for experimental and development purposes only. Autotools should be used for production builds. In 0.104+, we expect that CMake will be the preferred build system and will deprecate the use of Autotools. 2. https://koji.fedoraproject.org/koji/rpminfo?rpmID=24074656 /usr/sbin/clamonacc 197,280 (197K)
for reference: clamonacc crashes repeatedly in 0.103.0-1 packages from EPEL for CentOS and RHEL 7 https://bugzilla.redhat.com/show_bug.cgi?id=1918444 - above comment #9 uses "fedpkg --release epel7 local" and produces unstable 8k-clamonacc. what would be the appropriate procedure for packaging the 103-epel-rpm from https://src.fedoraproject.org/rpms/clamav.git and https://github.com/Cisco-Talos/clamav-devel/tree/rel/0.103 ? i appreciate your support!
(In reply to Hanspeter Gosteli from comment #11) > for reference: clamonacc crashes repeatedly in 0.103.0-1 packages from EPEL > for CentOS and RHEL 7 https://bugzilla.redhat.com/show_bug.cgi?id=1918444 - > above comment #9 uses "fedpkg --release epel7 local" and produces unstable > 8k-clamonacc. what would be the appropriate procedure for packaging the > 103-epel-rpm from https://src.fedoraproject.org/rpms/clamav.git and > https://github.com/Cisco-Talos/clamav-devel/tree/rel/0.103 ? i appreciate > your support! If I understood you , no , fedpkg --release epel7 mockbuild is more appropriated . fedpkg srpm && mock -r epel-7-x86_64 --no-clean --rebuild clamav-0.103.0-1.fc34.src.rpm well fedpkg srpm will write something like : Wrote: /home/sergio/fedora-scm/clamav/clamav-0.103.0-1.fc34.src.rpm and you may do: mock -r epel-7-x86_64 --rebuild /home/sergio/fedora-scm/clamav/clamav-0.103.0-1.fc34.src.rpm
thanks for the support! i compiled dev/0.103.1 and tcp streaming is working on rhel7 as described here: https://bugzilla.clamav.net/show_bug.cgi?id=12650 i propose this bugzilla to be closed. according to clamav-devel there should be a release of 0.103.1 in about 30 days and i hope we'll be able to fix the packaging by then as it's broken here: https://bugzilla.redhat.com/show_bug.cgi?id=1918444
The workaround is pretty straightforward isn't it? Use the TCPSocket/TCPAddr options in /etc/clamd.d/scan.conf instead of LocalSocket.
(In reply to Orion Poplawski from comment #14) > The workaround is pretty straightforward isn't it? Use the > TCPSocket/TCPAddr options in /etc/clamd.d/scan.conf instead of LocalSocket. Hi, with TCPSocket/TCPAddr options in /etc/clamd.d/scan.conf , `clamonacc --fdpass` is not allowed Review the situation : 1 - we have a bug 1918444 and I think with fix here [1] 2 - after we have a lots of fixes for clamonacc upstream [2] 3 - I'm thinking just apply [1] for now, to fix clamonacc on epel7 ASAP but after apply all patches for clamonacc from upstream, is not clear if will allow `clamonacc --fdpass` on EL7. The patch that we use initially for support clamonacc on EL 7 in clamav 0.102 allow it, so I'd like evaluate if it is possible enable `clamonacc --fdpass` again and if we should do it ? [1] https://github.com/Cisco-Talos/clamav-devel/commit/2b46876dcccd95eeb329477ba6f413eb485703a8 [2] https://github.com/Cisco-Talos/clamav-devel/compare/clamav-0.103.0...dev/0.104 https://github.com/Cisco-Talos/clamav-devel/compare/af8e628...dev/0.104
(In reply to Sergio Basto from comment #15) > (In reply to Orion Poplawski from comment #14) > > The workaround is pretty straightforward isn't it? Use the > > TCPSocket/TCPAddr options in /etc/clamd.d/scan.conf instead of LocalSocket. > > Hi, > > with TCPSocket/TCPAddr options in /etc/clamd.d/scan.conf , `clamonacc > --fdpass` is not allowed Sure, but we don't specify --fdpass anywhere in the stock clamonacc config. > > Review the situation : > > 1 - we have a bug 1918444 and I think with fix here [1] Yes, that looks like a likely fix. I tested with full dev/0.103.1 and it looks better. > 2 - after we have a lots of fixes for clamonacc upstream [2] > > 3 - I'm thinking just apply [1] for now, to fix clamonacc on epel7 ASAP Agreed. Can you take this on? > but after apply all patches for clamonacc from upstream, is not clear if > will allow `clamonacc --fdpass` on EL7. > The patch that we use initially for support clamonacc on EL 7 in clamav > 0.102 allow it, so I'd like evaluate if it is possible enable `clamonacc > --fdpass` again and if we should do it ? I don't think there is any way to enable fdpass with clamonacc and the stock libcurl. The previous patch has essentially be merged by upstream now, but for some reason 7.40 is required for fdpass - I don't know why.
(In reply to Orion Poplawski from comment #16) > The previous patch has essentially be merged by upstream now, but > for some reason 7.40 is required for fdpass - I don't know why. https://src.fedoraproject.org/rpms/clamav/blob/e76df38561125e90a4f7aa2cecce5248bbc9a5c1/f/clamav-curl.patch https://github.com/Cisco-Talos/clamav-devel/commit/29389cb7745bc46a6054b0cb3564e36635a73abc#diff-1b94821222a4694d2b7b44ee42cd7fad1e1301c515fa18eae27c76c737ed80caR331 the difference is clamav patch have "if optget(ctx->opts, "fdpass")->enabled kick out" and our patch not ...
I'm assuming that the clamav folks actually determined that fdpass would not work properly with libcurl < 7.40.
From https://curl.se/changes.html: Fixed in 7.40.0 - January 8 2015 Changes: Added support for HTTP over unix domain sockets, via CURLOPT_UNIX_SOCKET_PATH and --unix-socket
Ok , so maybe we should change the defaults on EL7 ? , to work out of the box . or is not a bug ?
We don't set any defaults out of the box that don't work. But if people choose to use unix sockets (LocalSocket) vs TCP it will fail. We probably should add a warning to /etc/clamd.d/scan.conf in the LocalSocket section about it.
tcp socket streaming seems to fail in some cases on detecting eicar file creation. in some environments this happens very rarely and is hard to detect. https://bugzilla.clamav.net/show_bug.cgi?id=12667
Thanks for the info, but unfortunately that bug is currently private so I can't see it. Could you add me to the cc list or request to open it up? Thanks.
Gents, would anyone oppose static inclusion of libcurl? We've POCd it here while observing major benefits: https://github.com/Cisco-Talos/clamav/issues/199 ... note also that clamAV is moving to CMAKE so an overhaul might be needed also. Do you agree if we PR the static inclusion of CURL? Thanks
I don't like but if it is important, I don't mind