Re: [clamav-users] Main CVD and Main Cdiff have been published

The main.cld is equivalent to main.cvd and the date is correct. The difference is one is compressed, the other not. dp On 6/8/17 9:30 PM, mlnl wrote: Hi, should this be correct? -rw-r--r--. 1 clam clam654336 Jun 7 03:18 bytecode.cld -rw-r--r--. 1 clam clam 123921920 Jun 9 03:26

Re: [clamav-users] Main CVD and Main Cdiff have been published

Hi, > should this be correct? > > -rw-r--r--. 1 clam clam654336 Jun 7 03:18 bytecode.cld > -rw-r--r--. 1 clam clam 123921920 Jun 9 03:26 daily.cld > -rw-r--r--. 1 clam clam 307499008 Jun 8 03:18 main.cld ls -la *.cld -rw-r--r-- 1 clamav clamav654336 Jun 7 06:06 bytecode.cld

Re: [clamav-users] Main CVD and Main Cdiff have been published

On 6/8/2017 8:56 PM, Walter H. wrote: On 08.06.2017 04:43, Al Varnell wrote: main.cvd is 117,892,267 bytes main-58.cdiff is 8,808,462 bytes On Wed, Jun 07, 2017 at 04:55 PM, Dennis Peterson wrote: http://db.us.clamav.net/main-58.cdiff -Al- should this

Re: [clamav-users] Main CVD and Main Cdiff have been published

On 08.06.2017 04:43, Al Varnell wrote: main.cvd is 117,892,267 bytes main-58.cdiff is 8,808,462 bytes On Wed, Jun 07, 2017 at 04:55 PM, Dennis Peterson wrote: http://db.us.clamav.net/main-58.cdiff -Al- should this be correct? -rw-r--r--. 1 clam clam

Re: [clamav-users] Main CVD and Main Cdiff have been published

On 6/8/2017 8:47 PM, Walter H. wrote: On 08.06.2017 00:20, Joel Esler (jesler) wrote: As promised, we were able to ship a new Main.cvd and the cdiff for the main.cvd a few minutes ago. It should have hit the mirrors in the past few minutes. As always, this will increase the amount of traffic

Re: [clamav-users] Main CVD and Main Cdiff have been published

On 08.06.2017 00:20, Joel Esler (jesler) wrote: As promised, we were able to ship a new Main.cvd and the cdiff for the main.cvd a few minutes ago. It should have hit the mirrors in the past few minutes. As always, this will increase the amount of traffic on the mirrors from people

Re: [clamav-users] High freshclam process' CPU usage since last night PDT...

Ah, it is a known issue. Thanks, Al. I will wait. Yeah, this is an issue for slow machines like mine. :( On 6/8/2017 3:19 PM, Al Varnell wrote: Phillip, Did you see this earlier today? On Thu, Jun 08, 2017 at 05:13 AM, Mark Allan wrote: For some reason, applying the 4MB daily-23454.cdiff

Re: [clamav-users] High freshclam process' CPU usage since last night PDT...

Phillip, Did you see this earlier today? On Thu, Jun 08, 2017 at 05:13 AM, Mark Allan wrote: > For some reason, applying the 4MB daily-23454.cdiff file took a really long > time, even on a fast machine - 6 minutes on a 2.6 GHz intel core i7 > > Curiously, the main-58.cdiff took only a fraction

[clamav-users] High freshclam process' CPU usage since last night PDT...

Hello. My updated 64-bit Debian's stable/Jessie's top shows "4959 clamav20 0 106684 22856 12836 R 100.0 1.1 0:58.70 freshclam". Its /var/log/clamav/freshclam.log's ending show: Thu Jun 8 14:43:18 2017 -> -- Thu Jun 8 14:43:18 2017 -> freshclam

Re: [clamav-users] Lots of "fmap_readpage" errors with ClamAV 0.99.2 on centos 7

Hi, You could try setting "Debug true" in your clamd.conf file, or use clamscan --debug, to obtain some more info about the issue. Using debug mode will produce lots of output. If you post it somewhere, I'll take a look at it. Steve -Original Message- From: clamav-users

Re: [clamav-users] Main CVD and Main Cdiff have been published

For some reason, applying the 4MB daily-23454.cdiff file took a really long time, even on a fast machine - 6 minutes on a 2.6 GHz intel core i7 Curiously, the main-58.cdiff took only a fraction of that time (less than 30 seconds) to apply, despite being twice the size. So I'm wondering, when

[clamav-users] Lots of "fmap_readpage" errors with ClamAV 0.99.2 on centos 7

Hello, I'm running a freshly installed centos 7 box with this vagrant image: https://atlas.hashicorp.com/centos/boxes/7 SELinux is set to disabled. ClamAV is installed from EPEL, and is running with this configuration: https://pastebin.com/JZqPHc05 It works properly, and succeeds in detecting