[clamav-users] need to kill clamscan with pkill
Hi list, So I read the documentation and maybe I missed something but I have to use pkill -9 clamscan to end the scan that is scheduled (through clamtk) for 22:59. I'm running Debian Bookworm that is updated daily. The results from clamconf -n Checking configuration files in /etc/clamav Config file: clamd.conf --- PreludeAnalyzerName = "ClamAV" LogFile = "/var/log/clamav/clamav.log" LogFileMaxSize = "4294967295" LogTime = "yes" LogSyslog = "yes" LogRotate = "yes" ExtendedDetectionInfo = "yes" LocalSocket = "/var/run/clamav/clamd.ctl" LocalSocketGroup = "clamav" LocalSocketMode = "666" MaxConnectionQueueLength = "15" StreamMaxLength = "26214400" MaxThreads = "12" ReadTimeout = "180" SendBufTimeout = "200" FollowFileSymlinks = "yes" SelfCheck = "3600" User = "clamav" BytecodeTimeout = "6" MaxScanTime = "12" MaxScanSize = "104857600" MaxFileSize = "26214400" MaxRecursion = "16" MaxEmbeddedPE = "10485760" MaxHTMLNormalize = "10485760" MaxHTMLNoTags = "2097152" MaxScriptNormalize = "5242880" PCREMatchLimit = "1" PCRERecMatchLimit = "5000" PCREMaxFileSize = "26214400" Config file: freshclam.conf --- LogFileMaxSize = "4294967295" LogTime = "yes" LogRotate = "yes" UpdateLogFile = "/var/log/clamav/freshclam.log" Checks = "24" DatabaseMirror = "db.local.clamav.net", "database.clamav.net" MaxAttempts = "5" ReceiveTimeout disabled Config file: clamav-milter.conf --- LogFile = "/var/log/clamav/clamav-milter.log" LogTime = "yes" LogRotate = "yes" PidFile = "/var/run/clamav/clamav-milter.pid" TemporaryDirectory = "/tmp" User = "clamav" MaxFileSize = "26214400" ClamdSocket = "unix:/var/run/clamav/clamd.ctl" MilterSocket = "/var/run/clamav/clamav-milter.ctl" MilterSocketGroup = "clamav" MilterSocketMode = "666" AddHeader = "Replace" LogInfected = "Off" LogClean = "Off" Software settings - Version: 1.0.1 Optional features supported: MEMPOOL AUTOIT_EA06 BZIP2 LIBXML2 PCRE2 ICONV JSON RAR Database information Database directory: /var/lib/clamav daily.cld: version 26827, sigs: 2022011, built on Wed Mar 1 02:28:49 2023 main.cvd: version 62, sigs: 6647427, built on Thu Sep 16 07:32:42 2021 bytecode.cvd: version 334, sigs: 91, built on Wed Feb 22 15:33:21 2023 Total number of signatures: 8669529 Platform information uname: Linux 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) x86_64 OS: Linux, ARCH: x86_64, CPU: x86_64 Full OS version: No LSB modules are available. Debian GNU/Linux bookworm/sid zlib version: 1.2.13 (1.2.13), compile flags: a9 platform id: 0x0a21a1a1080c0200 Build information - GNU C: 12.2.0 (12.2.0) sizeof(void*) = 8 Engine flevel: 161, dconf: 161 The only thing I can find in the log files is the one named "clamonacc.log" which has multiple entries of: ERROR: Clamonacc: at least one of OnAccessExcludeUID, OnAccessExcludeUname, or OnAccessExcludeRootUID must be specified ... it is recommended you exclude the clamd instance UID or uname to prevent infinite event scanning loops. I'm assuming that is what's happening but I can't find where to get the information that is requested in that message or how to fix it. Prior to using pkill clamscan has my CPU at 100% The Cron job command (/usr/bin/clamscan --exclude- dir=/home/tmick/.clamtk/viruses --exclude-dir=smb4k --exclude- dir=/run/user/tmick/gvfs --exclude-dir=/home/tmick/.gvfs --exclude- dir=.thunderbird --exclude-dir=.mozilla-thunderbird --exclude- dir=.evolution --exclude-dir=Mail --exclude-dir=kmail -i --detect-pua -r /home/tmick --log="$HOME/.clamtk/history/$(date +%b-%d-%Y).log" 2>/dev/null # clamtk-scan)I have run manually and it succeeds fine. I'm confused and thanks for the help in advance. -- Tim McConnell ___ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
Re: [clamav-users] Long database load time, long clamscan scan time
Dear Micah, thanks for this information. Please let us know, if the problem is solved. By the way, what is Cisco's or Talo's definition of the word "daily"? Means that, on every day beginning on 12 am? Kind regards Marc Am 1. März 2023 18:59:57 schrieb "Micah Snyder \(micasnyd\) via clamav-users" : All, We're aware of the issue with the latest daily database update causing extremely long database load times and thus extremely long clamscan scan times. We found the issue and will push out a fix as soon as we are able. We are also preparing guardrails so that this won't happen again in this way. Our apologies for the inconvenience. Regards, Micah Micah Snyder ClamAV Development Talos Cisco Systems, Inc. ___ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat ___ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
[clamav-users] Long database load time, long clamscan scan time
All, We're aware of the issue with the latest daily database update causing extremely long database load times and thus extremely long clamscan scan times. We found the issue and will push out a fix as soon as we are able. We are also preparing guardrails so that this won't happen again in this way. Our apologies for the inconvenience. Regards, Micah Micah Snyder ClamAV Development Talos Cisco Systems, Inc. ___ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
Re: [clamav-users] 0 length bytecode.cvd causing problems with clamav daemon
Hi Micah, I appreciate your response. It has been driving me nuts since it started about a week ago. Things had been humming along nicely for over a year until ~22 Feb. So, as best I can tell at this point, the mirror does not have a bytecode.cvd to serve up (0 length or otherwise). Here is a listing of /var/lib/clamav on the mirror. koconnor@ampion-clamav-mirror:~$ ls -l /var/lib/clamav total 226196 -rw-r--r-- 1 clamav clamav314802 Feb 22 22:02 bytecode.cld -rw-r--r-- 1 clamav clamav 60814501 Mar 1 09:07 daily.cld -rw-r--r-- 1 clamav clamav69 Jan 29 2022 freshclam.dat -rw-r--r-- 1 clamav clamav 170479789 Jan 29 2022 main.cvd -rw-r--r-- 1 clamav clamav87 Jan 29 2022 test.html This is the version of freshclam on the mirror: koconnor@ampion-clamav-mirror:~$ freshclam -V ClamAV 0.103.8/26827/Wed Mar 1 08:28:49 2023 And the freshclam.conf on the mirror too. koconnor@ampion-clamav-mirror:~$ cat /etc/clamav/freshclam.conf # Automatically created by the clamav-freshclam postinst # Comments will get lost when you reconfigure the clamav-freshclam package DatabaseOwner clamav UpdateLogFile /var/log/clamav/freshclam.log LogVerbose false LogSyslog false LogFacility LOG_LOCAL6 LogFileMaxSize 0 LogRotate true LogTime true Foreground false Debug false MaxAttempts 5 DatabaseDirectory /var/lib/clamav DNSDatabaseInfo current.cvd.clamav.net ConnectTimeout 30 ReceiveTimeout 0 TestDatabases yes ScriptedUpdates yes CompressLocalDatabase yes Bytecode true NotifyClamd /etc/clamav/clamd.conf # Check for new database 24 times a day Checks 24 DatabaseMirror db.local.clamav.net DatabaseMirror database.clamav.net I did find something interesting in the logs on the mirror server. First a listing of the log directory: koconnor@ampion-clamav-mirror:~$ ls -l /var/log/clamav/* -rw-r- 1 clamav clamav 57381 Mar 1 13:07 /var/log/clamav/freshclam.log -rw-r- 1 clamav adm142086 Feb 26 00:00 /var/log/clamav/freshclam.log.1 -rw-r- 1 clamav clamav 5142 Dec 25 00:00 /var/log/clamav/freshclam.log.10.gz -rw-r- 1 clamav adm 5002 Dec 18 00:00 /var/log/clamav/freshclam.log.11.gz -rw-r- 1 clamav adm 5008 Dec 11 00:00 /var/log/clamav/freshclam.log.12.gz -rw-r- 1 clamav adm 6158 Feb 19 00:00 /var/log/clamav/freshclam.log.2.gz -rw-r- 1 clamav adm 4997 Feb 12 00:00 /var/log/clamav/freshclam.log.3.gz -rw-r- 1 clamav clamav 5148 Feb 5 00:00 /var/log/clamav/freshclam.log.4.gz -rw-r- 1 clamav adm 5023 Jan 29 00:00 /var/log/clamav/freshclam.log.5.gz -rw-r- 1 clamav adm 5008 Jan 22 00:00 /var/log/clamav/freshclam.log.6.gz -rw-r- 1 clamav adm 4990 Jan 15 00:00 /var/log/clamav/freshclam.log.7.gz -rw-r- 1 clamav adm 5009 Jan 8 00:00 /var/log/clamav/freshclam.log.8.gz -rw-r- 1 clamav clamav 5174 Jan 1 00:00 /var/log/clamav/freshclam.log.9.gz Then a search for bytecode.cvd in the most recent log file: koconnor@ampion-clamav-mirror:~$ sudo grep bytecode.cvd /var/log/clamav/freshclam.log koconnor@ampion-clamav-mirror:~$ Followed by a search for that string in the next most recent file: koconnor@ampion-clamav-mirror:~$ sudo grep bytecode.cvd /var/log/clamav/freshclam.log.1 Sun Feb 19 00:00:35 2023 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2) Sun Feb 19 01:00:35 2023 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2) Sun Feb 19 02:00:35 2023 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2) Sun Feb 19 03:00:35 2023 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2) this is repeated every hour Wed Feb 22 18:02:30 2023 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2) Wed Feb 22 19:02:31 2023 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2) Wed Feb 22 20:02:31 2023 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2) Wed Feb 22 21:02:31 2023 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2) koconnor@ampion-clamav-mirror:~$ This is particularly interesting as the end of that output is approximately the time when the problem started. Let me know if I should send you a copy of any of the log files from the mirror. I wasn't sure if that was appropriate for the listserv. Thanks again Kevin On Tue, Feb 28, 2023 at 1:31 PM Micah Snyder (micasnyd) wrote: > The bytecode.cvd file is the original. > When there is an update, we publish two things: > >1. a bytecode.cdiff patch file that will update the older bytecode.cvd >to the newest version. This is the "scripted update" mechanism. > >If using the .cdiff patch file to update, it should replace the old >bytecode.cvd with a new bytecode.cld. We may issue an empty patch >file
