After setting up clamav-daemon, I suspect it's having the same issue,
based on the 11 minute "stall" part way through the initialisation.
Tue Apr 6 16:26:14 2021 -> +++ Started at Tue Apr 6 16:26:14 2021
Tue Apr 6 16:26:14 2021 -> Received 0 file descriptor(s) from systemd.
Tue Apr 6 16:26:14 2021 -> clamd daemon 0.102.4 (OS: linux-gnu, ARCH:
i386, CPU: i686)
Tue Apr 6 16:26:14 2021 -> Running as user clamav (UID 108, GID 114)
Tue Apr 6 16:26:14 2021 -> Log file size limited to 4294967295 bytes.
Tue Apr 6 16:26:14 2021 -> Reading databases from /var/lib/clamav
Tue Apr 6 16:26:14 2021 -> Not loading PUA signatures.
Tue Apr 6 16:26:14 2021 -> Bytecode: Security mode set to "TrustSigned".
Tue Apr 6 16:27:56 2021 -> Loaded 8518548 signatures.
Tue Apr 6 16:39:22 2021 -> LOCAL: Removing stale socket file
/var/run/clamav/clamd.ctl
Tue Apr 6 16:39:22 2021 -> LOCAL: Unix socket file
/var/run/clamav/clamd.ctl
Tue Apr 6 16:39:22 2021 -> LOCAL: Setting connection queue length to 15
Tue Apr 6 16:39:22 2021 -> Limits: Global time limit set to 120000
milliseconds.
... ... ...
Cheers.
On 4/6/2021 12:40 PM, Eddie via clamav-users wrote:
I can go back to bed and sleep. :-)
The only thing that runs on this server is the POP3 proxy code,
nothing else. And freshclam didn't pull any new signatures until
after the slowdown started. And take this with the same grain of salt
I used to, when I worked support: No, nothing was changed and the VM
is healthy.
Running --debug and tail'ing the output, these are the 2 points that
seem to account for almost all the 25 minutes:
--- Big snip ---
LibClamAV debug: Matcher[13]: INTERNAL: AC sigs: 0 (reloff: 0, absoff:
0) BM sigs: 0 (reloff: 0, absoff: 0) PCREs: 0 (reloff: 0, absoff: 0)
maxpatlen 0 (ac_only mode)
LibClamAV debug: Matcher[14]: OTHER: AC sigs: 0 (reloff: 0, absoff: 0)
BM sigs: 0 (reloff: 0, absoff: 0) PCREs: 0 (reloff: 0, absoff: 0)
maxpatlen 0 (ac_only mode)
---Very long wait here ---
LibClamAV debug: Building regex list
LibClamAV debug: Using filter for trie 0
LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0
LibClamAV debug: Building regex list
LibClamAV debug: Using filter for trie 0
LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0
--- More big snip ---
LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0
LibClamAV debug: cli_magic_scandesc: returning 0 at line 3202
LibClamAV debug: cache_add: 2e27d1964afc50a27f3b833a85047d8f (level 0)
/root/test.msg: OK
---Very long wait here ---
LibClamAV debug: Cleaning up phishcheck
LibClamAV debug: Freeing phishcheck struct
LibClamAV debug: Phishcheck cleaned up
Cheers.
On 4/6/2021 11:46 AM, Richard Graham wrote:
But I'd like to understand why, on Sunday morning, the scan time
which had been under a minute per mail, for over 4 months,
suddenly jumped to 25 minutes per mail and has remained at that.
It's a good question. Is there any way to reproduce what was
happening on Sunday morning? ... and then compare it to what is
happening today?
Has the size/location/access method to clamscan's signatures
changed? Is your system (drives, network, etc.) healthy?
On Tue, Apr 6, 2021 at 8:31 PM Eddie <stun...@attglobal.net
<mailto:stun...@attglobal.net>> wrote:
Understood, which is why I'm looking to move to clamdscan.
But I'd like to understand why, on Sunday morning, the scan time
which had been under a minute per mail, for over 4 months,
suddenly jumped to 25 minutes per mail and has remained at that.
Cheers.
On 4/6/2021 10:39 AM, Richard Graham wrote:
Clamscan can spend a looooong time loading signatures, etc. If
you run your command with strace (or monitor the process with
lsof, etc.) you'll probably see clamscan is busy accessing
signature files.
On Tue, Apr 6, 2021 at 5:44 PM Eddie via clamav-users
<clamav-users@lists.clamav.net
<mailto:clamav-users@lists.clamav.net>> wrote:
A POP3 proxy program I have running on a Debian 10.8 system,
uses
clamscan to check incoming e-mails. At some point in the
very early
morning (US West Coast time) it suddenly started taking a
very long time
to scan each mail, So much that the controlling process
would time out
before clamscan finished. Up to this point it was running fine.
Running a test from the command line, on a very simple
1-line mail took
around 25 minutes:
root@CleanMail:~# date ; clamscan test.msg -v --no-summary ;
date
Mon 05 Apr 2021 11:59:10 AM PDT
Scanning /root/test.msg
/root/test.msg: OK
Mon 05 Apr 2021 12:24:06 PM PDT
root@CleanMail:~#
Looking through the logs, I can't see anything happening in
the period
between the last good scan and the sloooooow ones.
Where should I be going next to track this down.
Cheers.
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
<mailto:clamav-users@lists.clamav.net>
https://lists.clamav.net/mailman/listinfo/clamav-users
<https://lists.clamav.net/mailman/listinfo/clamav-users>
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
<https://github.com/vrtadmin/clamav-faq>
http://www.clamav.net/contact.html#ml
<http://www.clamav.net/contact.html#ml>
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
