thanks Eric
1)ps aux | grep " /bin/spamd " | grep -v grep
nothing
2) /home/vpopmail/domains/'your
domain'/.qmail-default content
| /usr/bin/dspam --user "$EXT@$HOST" --deliver=stdout | /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox
Nice, I must only disable dspam service right?
Maybe the Lock wait timeout and bailing -2 was caused by that? Two proccess locking the same db?
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]1) See if an instance of spamd is already running, post the output to the list:
ps aux | grep " /bin/spamd " | grep -v grep
kill that process.
Try starting spamd.
2) Look in /home/vpopmail/domains/'your domain'/.qmail-default and see if dspam or dspamc is being called, post the output to the list.
If dspam is being called you can turn of the dspam daemon. If dspamc is being called keep the daemon running.
Eric
On 8/13/2020 6:20 PM, Diego Piñon Conde wrote:
Report :-)
Yesterday, as nobody here in my work trains spamassasin (I mean, really nobody), i has changed in dspam.conf TrainingMode notrain and Preference "trainingMode=notrain" , but in the second one by mistake I wrote it with caps on. I did not reinit dspam in that moment.
Today in the morning I realized not only that dspam failed to start, however clamd@scan is running ok.. What?
I had changed "trainingMode=NOTRAIN" to "trainingMode=notrain" but dspam did not start anyway.
systemctl status spamd.service says
● spamd.service - SYSV: spamd is a daemon process which uses SpamAssassin to check email messages for SPAM. It is normally called by spamc from a MDA.
Loaded: loaded (/etc/rc.d/init.d/spamd; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2020-08-13 21:06:00 -03; 5s ago
Docs: man:systemd-sysv-generator(8)
Process: 16976 ExecStop=/etc/rc.d/init.d/spamd stop (code=exited, status=0/SUCCESS)
Process: 13681 ExecStart=/etc/rc.d/init.d/spamd start (code=exited, status=1/FAILURE)
CGroup: /system.slice/spamd.service
├─ 6856 spamd child
├─10013 spamd child
└─20396 spamd child
Aug 13 21:05:58 pegasus spamd[13681]: server socket setup failed, retry 8: spamd: could not create IO...n use
Aug 13 21:05:59 pegasus spamd[13681]: spamd: could not create IO::Socket::IP socket on [::1]:783: Add...n use
Aug 13 21:05:59 pegasus spamd[13681]: server socket setup failed, retry 9: spamd: could not create IO...n use
Aug 13 21:06:00 pegasus spamd[13681]: spamd: could not create IO::Socket::IP socket on [::1]:783: Add...n use
Aug 13 21:06:00 pegasus spamd[13681]: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:78...n use
Aug 13 21:06:00 pegasus spamd[13681]: [FAILED]
Aug 13 21:06:00 pegasus systemd[1]: spamd.service: control process exited, code=exited status=1
Aug 13 21:06:00 pegasus systemd[1]: Failed to start SYSV: spamd is a daemon process which uses SpamAs...MDA..
Aug 13 21:06:00 pegasus systemd[1]: Unit spamd.service entered failed state.
Aug 13 21:06:00 pegasus systemd[1]: spamd.service failed.And yes, as netstat says, proccess 6856 use tcp port 783
netstat -lptn | grep 'spamd'
tcp 10 0 127.0.0.1:783 0.0.0.0:* LISTEN 6856/spamd child
tcp6 129 0 ::1:783 :::* LISTEN 6856/spamd child
But who is launchin that child process?
The good news is that I have not any more dspam bailing -2 and clamd servicer is runing :-)
El 11/08/2020 a las 10:49 a. m., Eric Broch escribió:
Okay. I just wanted to make sure that dspam wasn't being called twice.
This script installs /home/vpopmail/domains/mydomain.tld/.qmail-default with dspam enabled for whatever domain you choose.
There are other scripts /home/vpopmail/domains/mydomain.tld/myuser/.qmail and /home/vpopmail/domains/mydomain.tld/myuser/.mailfilter.dspam that are on github that one could install as well that would force a second calling of dspam. That's not what you would want.
Eric
On 8/11/2020 7:43 AM, Diego Piñon Conde wrote:
Hi Eric
This is part of the script that install dspam . It's attached in full too
# Install Dspam
read -p "Install dspam [Y/N] : " yesno
if [ "$yesno" = "Y" ] || [ "$yesno" = "y" ]; then
wget https://raw.githubusercontent.com/qmtoaster/dspam/master/dspamdb.sh
if [ "$?" != "0" ]; then
echo "Error downloading dspam installer, exiting..."
exit 1
fi
chmod 755 dspamdb.sh
./dspamdb.sh
if [ "$?" != 0 ]; then
echo "Error installing dspam"
fi
fi
echo "Enable QMT man pages..."
echo "MANDATORY_MANPATH /var/qmail/man" >> /etc/man_db.conf
El 10/08/2020 a las 08:24 p. m., Eric Broch escribió:
How did you install dspam?
On 8/10/2020 12:29 PM, Diego Piñon Conde wrote:
Sorry, I wanted to post the thank you to the lists but wrote direct to you...
mmm I don't know how answer that, but this is a recent installation (a think no more than 2 years) from the script for CentOS 7 on http://www.qmailtoaster.com/
I remember that in an old installation of toaster in CentOS 5 I has to installed spamdyke for my self, but as I can remeber here is included.Isnt it?
I didn't resolve yet ClamAv problem..
El 10/08/2020 a las 03:07 p. m., Eric Broch escribió:
How did you have dspam implemented?
Output .qmail-default, .qmail, and .mailfilter files.
Did you get clamd up and running?
Eric
On 8/10/2020 12:02 PM, Diego Piñon Conde wrote:
Thank you to all the guys who help me to reestablish my toaster, especially to Eric, Remo and Philip.
Do you think the real culprit off this mess was dspam?
if yes, do you think it is recommended to make a purge/clean of this db time to time? Or this was just a strange case?
At this stage spamdike was the only who use dspam isn't? Disabling spamdike could have allowed local queued emails to flow normally while the error was resolved?
Again, thank you Eric for your invaluable and selfless help and your great work with qmailtoaster.
El 08/08/2020 a las 06:45 p. m., Eric Broch escribió:
I'm not sure what to say at this point, maybe run the attached script.
All it does is reinstall the relevant packages and change the permissions appropriately
If that doesn't work, I saw Remo's offer for a Zoom session and their's always the ClamAV users' list.
I'd be interested to know the problem.
Eric
On 8/8/2020 12:01 PM, Diego Piñon Conde wrote:
sure!
root 6126 1.0 0.0 112812 964 pts/1 S+ 14:59 0:00 grep --color=auto clam
clamupd+ 30315 0.0 0.2 130376 4028 ? Ss 12:00 0:00 /usr/bin/freshclam -d --foreground=true
El 08/08/2020 a las 02:38 p. m., Eric Broch escribió:
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]can you do this
# ps aux |grep clam
and post output
On 8/8/2020 11:28 AM, Diego Piñon Conde wrote:
sorry for the delay Eric!, I was travelling to home...
Job for [email protected] failed because the control process exited with error code. See "systemctl status [email protected]" and "journalctl -xe" for details.
Did not start...
systemctl status [email protected]
● [email protected] - clamd scanner (scan) daemon
Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Sat 2020-08-08 14:15:23 -03; 3min 28s ago
Docs: man:clamd(8)
man:clamd.conf(5)
https://www.clamav.net/documents/
Process: 4316 ExecStart=/usr/sbin/clamd -c /etc/clamd.d/%i.conf (code=exited, status=1/FAILURE)
Aug 08 14:15:23 pegasus systemd[1]: Failed to start clamd scanner (scan) daemon.
Aug 08 14:15:23 pegasus systemd[1]: Unit [email protected] entered failed state.
Aug 08 14:15:23 pegasus systemd[1]: [email protected] failed.
Aug 08 14:15:23 pegasus systemd[1]: [email protected] holdoff time over, scheduling restart.
Aug 08 14:15:23 pegasus systemd[1]: Stopped clamd scanner (scan) daemon.
Aug 08 14:15:23 pegasus systemd[1]: start request repeated too quickly for [email protected]
Aug 08 14:15:23 pegasus systemd[1]: Failed to start clamd scanner (scan) daemon.
Aug 08 14:15:23 pegasus systemd[1]: Unit [email protected] entered failed state.
Aug 08 14:15:23 pegasus systemd[1]: [email protected] failed.
Hint: Some lines were ellipsized, use -l to show in full.
journalctl -xe
-- The result is failed.
Aug 08 14:15:23 pegasus systemd[1]: Unit [email protected] entered failed state.
Aug 08 14:15:23 pegasus systemd[1]: [email protected] failed.
Aug 08 14:15:23 pegasus systemd[1]: [email protected] holdoff time over, scheduling restart.
Aug 08 14:15:23 pegasus systemd[1]: Stopped clamd scanner (scan) daemon.
-- Subject: Unit [email protected] has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit [email protected] has finished shutting down.
Aug 08 14:15:23 pegasus systemd[1]: start request repeated too quickly for [email protected]
Aug 08 14:15:23 pegasus systemd[1]: Failed to start clamd scanner (scan) daemon.
-- Subject: Unit [email protected] has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit [email protected] has failed.
--
El 08/08/2020 a las 12:26 p. m., Eric Broch escribió:
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]Diego
Please try this new configuration file...
Attached is a new scan.conf (scan.conf.test).
put it into your directory /etc/clamd.d
# mv /etc/clamd.d/scan.conf /etc/clamd.d/scan.conf.bak
# mv /etc/clamd.d/scan.conf.test /etc/clamd.d/scan.conf
# systemctl start clamd@scan
Eric
On 8/8/2020 9:01 AM, Diego Piñon Conde wrote:
El 08/08/2020 a las 11:53 a. m., Eric Broch escribió:
Do this
# systemctl stop clamav-freshclam
# freshclam (post output)
# systemctl start clamav-freshclam
On 8/8/2020 8:42 AM, Diego Piñon Conde wrote:
El 08/08/2020 a las 11:24 a. m., Eric Broch escribió:
Also look in freshclam log (/var/log/clamav/freshclam.log)
# tail -n 20 /var/log/clamav/freshclam.log
post output here
On 8/8/2020 8:16 AM, Eric Broch wrote:
You can start simscan now, but keep clam=no in simcontrol until we can get clamd@scan started.
On 8/8/2020 6:40 AM, Diego Piñon Conde wrote:
I went to sleep at 2 in the morning with 2700 messages in local queue, now I can say is 0.
All thanks to all of you!
dspam_clean -s -p -u ended at 8:21 I guess because at that time is the last error for dspam. I keep searching the mail log for more errors.
Aug 8 08:21:37 pegasus dspam[17546]: query error: Deadlock found when trying to get lock; try restarting transaction: see sql.errors for more details
Aug 8 08:21:37 pegasus dspam[17546]: bailing on error -2
Aug 8 08:21:37 pegasus dspam[17546]: received invalid result (!DSR_ISSPAM && !DSR_ISINNOCENT): -2
clamd@scan still refuse to start, but I'm really don't sure I wanna use it. Virus db update takes forever and kill my server for at least 20 minutes, at least with clamAV version. I didn't get to test with the EPEL version...
Is this the time for enable simscan Eric? Yesterday replace simscan with qmail-queue in /etc/tcprules.d/tcp.smtp
El 07/08/2020 a las 11:08 p. m., Eric Broch escribió:
good!
you can run instead:
# dspam_clean -s -p -u
for all users
or
dspam_clean -s -p -u [email protected] [email protected] ... [email protected]
for the users you choose.
This will also purge the database.
On 8/7/2020 8:01 PM, Diego Piñon Conde wrote:
/purge-4.1.sql finally ends with no message
El vie., 7 ago. 2020 a las 19:28, Eric Broch (<[email protected]>) escribió:
optimize dspam also...
# mysql -u dspam -p dspam < /usr/share/dspam/sql-scripts/mysql/purge-4.1.sql
On 8/7/2020 4:24 PM, Eric Broch wrote:
what's this yield
# ls -la /var/log/clamd
On 8/7/2020 4:19 PM, Diego Piñon Conde wrote:
Same error
systemctl start clamd@scan
Job for [email protected] failed because a timeout was exceeded. See "systemctl status [email protected]" and "journalctl -xe" for details.
El vie., 7 ago. 2020 a las 19:08, Eric Broch (<[email protected]>) escribió:
run the following and try to restart clamd@scan
curl -o /etc/clamd.d/scan.conf https://raw.githubusercontent.com/qmtoaster/scripts/master/scan.confOn 8/7/2020 4:05 PM, Diego Piñon Conde wrote:
systemctl start clamd@scan Job for [email protected] failed because a timeout was exceeded. See "systemctl status [email protected]" and "journalctl -xe" for details.
Did Not start
El vie., 7 ago. 2020 a las 18:44, Eric Broch (<[email protected]>) escribió:
don't stop it. allow it to go until it starts. sometimes it takes quite a while.
On 8/7/2020 3:39 PM, Diego Piñon Conde wrote:
systemctl start clamd@scan
freeze and do nothing
# ls -ld /var/log/dspam
drwxrwx--- 2 dspam mail 81 Feb 18 03:57 /var/log/dspam
# ls -la /var/log/dspam
total 10256
drwxrwx--- 2 dspam mail 81 Feb 18 03:57 .
drwxr-xr-x. 16 root root 4096 Aug 7 17:53 ..
-rw-r--r-- 1 dspam mail 0 Feb 18 03:57 sql.errors
-rw-rw---- 1 vpopmail mail 10493507 Feb 18 01:53 sql.errors-20200218
-rw------- 1 dspam mail 0 Feb 18 03:57 sql.errors-20200218.gz
El vie., 7 ago. 2020 a las 18:31, Eric Broch (<[email protected]>) escribió:
What's the output of the following commands?
# ls -ld /var/log/dspam
and
# ls -la /var/log/dspam
On 8/7/2020 2:46 PM, Diego Piñon Conde wrote:
This is the only weird message i can repeated times see from now
[00 ]Aug 7 17:40:54 pegasus dspam[19962]: Unable to open file for writing: /var/log/dspam/sql.errors: Permission denied
[00]Aug 7 17:40:55 pegasus dspam[19962]: bailing on error -2
[00]Aug 7 17:40:55 pegasus dspam[19962]: received invalid result (!DSR_ISSPAM && !DSR_ISINNOCENT): -2
[00]Aug 7 17:40:55 pegasus dspam[19962]: process_message returned error -5. delivering.
I 'm still looking
El vie., 7 ago. 2020 a las 17:06, Philip Nix Guru (<[email protected]>) escribió:
Hello
a bit hard to debug without checking system
if you got multitail
create a file with :
multitail -Z red,black,inverse -T -S -x "%m %u@%h %f (%t) [%l]" \
-m 0 -n 49 -cS qmail-send -l "qmlog -f send" \
-m 0 -n 49 -cS qmail-smtp3 -em "policy_check" -em "CHKUSER" -em "simscan" -em "spamdyke" -em "qmail-smtpd: " -l "qmlog -f smtp" \
-m 0 -n 49 -cS qmtspamassassin -ev "prefork" -ev "(connection from localhost)" -l "tail -f /var/log/maillog" \
# -m 0 -n 49 -cS qmail-smtp -em "policy_check" -em "CHKUSER" -em "simscan" -em "spamdyke" -em "qmail-smtpd: " -em "spf-reject" -l "qmlog -f submission" \
# -m 0 -n 49 -cS qmtspamassassin -ev "prefork" -ev "(connection from localhost)" -l "tail -f /var/log/maillog"
and just sh it, and check if you see anything weird/strange, delay ...
in the mail transaction
The amount of messages in the local queue is still descending but I don't know why so slow!
El vie., 7 ago. 2020 a las 15:48, Philip Nix Guru (<[email protected]>) escribió:
Hello
But the mail does get delivered just with a very long delay ?
and you disabled clamd but it still running ?
Check a delivered mail, look at the headers, make sure clamd is really not running
anything suspicous in /var/log/clamd/clamd.log ?
qmHandle -s shows what ?
On 8/7/20 8:34 PM, Diego Piñon Conde wrote:
2 hs has passed and the local queue has 3530 msg (it was 3700 at some point). Beside clamd that it is still running and time to time take 100% cpu usage (I don't understand why because qmailtoaster it's supoust that not use it anymore), cpu usage is normally below 20% and memory is the same. So why does it take so long to deliver local msg!
I'm in UTC -3, so probably all of you are snoring. I will keep working til qmailtoaster works normally, I hope when you wake up you can give me a hand.
I will really appreciate that. Thanks in advance!
El vie., 7 ago. 2020 a las 12:29, Philip Nix Guru (<[email protected]>) escribió:
Hello
what you could start by doing is disabling
idle-timeout-secs=xx in /etc/spamdyke/spamdyke.conf
just comment the line
check in a few hours if your TIMEOUT drastically decreased
then you can adapt the idle-timeout delay
If not then, we can check other things
Cheers
On 8/7/20 4:40 PM, Diego Piñon Conde wrote:
Hi Philipthis is the tail of /var/log/maillog
Aug 7 11:31:01 pegasus spamdyke[2968]: TIMEOUT from: [email protected] to: [email protected] origin_ip: 209.85.215.175 origin_rdns: mail-pg1-f175.google.com auth: (unknown) encryption: TLS reason: TIMEOUT
Aug 7 11:31:03 pegasus spamdyke[2970]: TIMEOUT from: [email protected] to: [email protected] origin_ip: 209.167.231.144 origin_rdns: mail01.messages.sonicwall.com auth: (unknown) encryption: TLS reason: TIMEOUT
Aug 7 11:31:03 pegasus spamdyke[2969]: TIMEOUT from: v-cjcdika_pmnlhikcme_gmicmlkp_gmicmlk...@bounce.info.bancopatagonia.com.ar to: [email protected] origin_ip: 192.156.219.80 origin_rdns: mail7756.info.bancopatagonia.com.ar auth: (unknown) encryption: TLS reason: TIMEOUT
Aug 7 11:31:06 pegasus spamdyke[2974]: TIMEOUT from: bounce-10710_html-121882056-2177875-6399888-...@bounce.mail.bbva.com.ar to: [email protected] origin_ip: 13.111.6.12 origin_rdns: mta.mail.bbva.com.ar auth: (unknown) encryption: TLS reason: TIMEOUT
Aug 7 11:31:24 pegasus vpopmail[3225]: vchkpw-submission: (PLAIN) login success [email protected]:10.10.10.8
Aug 7 11:31:27 pegasus spamdyke[3004]: TIMEOUT from: [email protected] to: [email protected] origin_ip: 91.211.241.9 origin_rdns: pmta41009.emsmtp.com auth: (unknown) encryption: TLS reason: TIMEOUT
Aug 7 11:31:32 pegasus spamdyke[3006]: TIMEOUT from: [email protected] to: [email protected] origin_ip: 40.107.76.91 origin_rdns: mail-eopbgr760091.outbound.protection.outlook.com auth: (unknown) encryption: TLS reason: TIMEOUT
Aug 7 11:31:34 pegasus spamdyke[3050]: TIMEOUT from: [email protected] to: [email protected] origin_ip: 190.210.19.10 origin_rdns: webmail.provinciaseguros.com auth: (unknown) encryption: TLS reason: TIMEOUT
Aug 7 11:31:38 pegasus spamdyke[3074]: TIMEOUT from: [email protected] to: [email protected] origin_ip: 209.85.210.45 origin_rdns: mail-ot1-f45.google.com auth: (unknown) encryption: TLS reason: TIMEOUT
Aug 7 11:31:42 pegasus spamdyke[3158]: TIMEOUT from: [email protected] to: [email protected] origin_ip: 200.41.224.100 origin_rdns: mail.mardelplata.gov.ar auth: (unknown) encryption: (none) reason: TIMEOUT
I've checked scan.conf and logverbose = yes
El vie., 7 ago. 2020 a las 11:27, Philip Nix Guru (<[email protected]>) escribió:
Hello
can you check if you got any
TIMEOUT in /var/log/maillog log file
since you did your update
Check also your scan.conf file
/etc/clamd.d/scan.conf
Enable Log (verbose) ,
LogVerbose yes
On 8/7/20 4:12 PM, Diego Piñon Conde wrote:
Hi all
I'm running qmail toaster on CentOS 7.
Because I had problems with freshclam (terrible slow db update), yesterday I changed clamAV to Epel version.
I don't know if it's relevant, but after that local delivery was too slow.
Local queue was increasing in size and every email received by clients was received 5 or 6 times.
I thinked maybe clamd it's the culprit, so I've changed clamd=no in simcontrol and did qmailctl cdb but nothing has changed.
My knowledge is limited and I will appreciate any help--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
sorry, i didn't send it to the list
here it is...
Sat Aug 8 10:39:30 2020 -> download_complete_callback: Download complete for database : /var/lib/clamav/tmp.a7a50/clamav-3329f7f83f3cf3a1d4e511ecbf21cf06.tmp-daily.cld
Sat Aug 8 10:39:30 2020 -> download_complete_callback: fc_context->bTestDatabases : 1
Sat Aug 8 10:39:30 2020 -> download_complete_callback: fc_context->bBytecodeEnabled : 1
Sat Aug 8 10:39:30 2020 -> Testing database: '/var/lib/clamav/tmp.a7a50/clamav-3329f7f83f3cf3a1d4e511ecbf21cf06.tmp-daily.cld' ...
Sat Aug 8 10:39:31 2020 -> Loading signatures from /var/lib/clamav/tmp.a7a50/clamav-3329f7f83f3cf3a1d4e511ecbf21cf06.tmp-daily.cld
Sat Aug 8 10:40:01 2020 -> Properly loaded 3835881 signatures from /var/lib/clamav/tmp.a7a50/clamav-3329f7f83f3cf3a1d4e511ecbf21cf06.tmp-daily.cld
Sat Aug 8 10:40:05 2020 -> Database test passed.
Sat Aug 8 10:40:05 2020 -> daily.cld updated (version: 25898, sigs: 3807234, f-level: 63, builder: raynman)
Sat Aug 8 10:40:06 2020 -> fc_update_database: daily.cld updated.
Sat Aug 8 10:40:06 2020 -> Current working dir is /var/lib/clamav/
Sat Aug 8 10:40:06 2020 -> check_for_new_database_version: Local copy of main found: main.cld.
Sat Aug 8 10:40:06 2020 -> query_remote_database_version: main.cvd version from DNS: 59
Sat Aug 8 10:40:06 2020 -> main.cld database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
Sat Aug 8 10:40:06 2020 -> fc_update_database: main.cld already up-to-date.
Sat Aug 8 10:40:06 2020 -> Current working dir is /var/lib/clamav/
Sat Aug 8 10:40:06 2020 -> check_for_new_database_version: Local copy of bytecode found: bytecode.cld.
Sat Aug 8 10:40:06 2020 -> query_remote_database_version: bytecode.cvd version from DNS: 331
Sat Aug 8 10:40:06 2020 -> bytecode.cld database is up to date (version: 331, sigs: 94, f-level: 63, builder: anvilleg)
Sat Aug 8 10:40:06 2020 -> fc_update_database: bytecode.cld already up-to-date.
Sat Aug 8 10:40:06 2020 -> --------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]Done
Sat Aug 8 11:59:26 2020 -> ClamAV update process started at Sat Aug 8 11:59:26 2020
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Sat Aug 8 11:59:26 2020 -> *Current working dir is /var/lib/clamav/
Sat Aug 8 11:59:26 2020 -> *Querying current.cvd.clamav.net
Sat Aug 8 11:59:26 2020 -> *TTL: 1715
Sat Aug 8 11:59:26 2020 -> *fc_dns_query_update_info: Software version from DNS: 0.102.4
Sat Aug 8 11:59:26 2020 -> *Current working dir is /var/lib/clamav/
Sat Aug 8 11:59:26 2020 -> *check_for_new_database_version: Local copy of daily found: daily.cld.
Sat Aug 8 11:59:26 2020 -> *query_remote_database_version: daily.cvd version from DNS: 25898
Sat Aug 8 11:59:26 2020 -> daily.cld database is up to date (version: 25898, sigs: 3807234, f-level: 63, builder: raynman)
Sat Aug 8 11:59:26 2020 -> *fc_update_database: daily.cld already up-to-date.
Sat Aug 8 11:59:26 2020 -> *Current working dir is /var/lib/clamav/
Sat Aug 8 11:59:26 2020 -> *check_for_new_database_version: Local copy of main found: main.cld.
Sat Aug 8 11:59:26 2020 -> *query_remote_database_version: main.cvd version from DNS: 59
Sat Aug 8 11:59:26 2020 -> main.cld database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
Sat Aug 8 11:59:26 2020 -> *fc_update_database: main.cld already up-to-date.
Sat Aug 8 11:59:26 2020 -> *Current working dir is /var/lib/clamav/
Sat Aug 8 11:59:26 2020 -> *check_for_new_database_version: Local copy of bytecode found: bytecode.cld.
Sat Aug 8 11:59:26 2020 -> *query_remote_database_version: bytecode.cvd version from DNS: 331
Sat Aug 8 11:59:26 2020 -> bytecode.cld database is up to date (version: 331, sigs: 94, f-level: 63, builder: anvilleg)
Sat Aug 8 11:59:26 2020 -> *fc_update_database: bytecode.cld already up-to-date.
