--On 25 May 2019 at 22:24:32 -0700 Al Varnell via clamav-users
wrote:
Appears to be a malformed hex string in 3rd logical expression:
* SUBSIG ID 2
+-> OFFSET: ANY
+-> SIGMOD: NONE
+-> DECODED SUBSIGNATURE:
LibClamAV Error: cli_hex2ui(): Malformed hexstring: 1 (length: 1)
ERROR: Decod
--On 25 May 2019 at 11:25:46 -0400 Tuffmail Support
wrote:
Same here with FreeBSD 11.1 and clamav-0.101.2. Yesterday 0, today
several hundred so far.
Thanks for the heads up!
Good to know I'm not the only one - but it'd be really handy to be able to
get freshclam to either keep the las
Hi All,
Our system updated today:
May 25 09:24:20 daily.cld updated (version: 25460, sigs: 1581004, f-level:
63, builder: raynman)
(Time is BST - i.e. UTC+1)
After that we saw a large number of viruses found - all detected as
Win.Exploit.CVE_2019_0903-6966169-0
This seems to be includi
--On 24 September 2018 11:31 +0100 Mark Fortescue
wrote:
Hi Micah,
Can you not have a two part demon process. Part one fork's the real demon
and then waits for it to die (with 'wait()').
On death of the child, it cleans up and exits. Yes I know it is not quite
as simple as that. It will h
--On 21 September 2018 17:14 +0100 "G.W. Haywood"
wrote:
Hi there,
On Fri, 21 Sep 2018, Karl Pielorz wrote:
... it gets delivered if it fails during the scan ...
It doesn't have to be that way, and if someone knows a way to stop
clamd then maybe they could use it t
--On 20 September 2018 15:44 + "Micah Snyder (micasnyd)"
wrote:
Clamd has a FixStaleSocket option that is default on.
FixStaleSocket will unlink the lingering stale socket and bind again if
it failed to bind when restarting clamd.
Hi, yeah - I saw that option.
I all ears if anyone
--On 19 September 2018 16:43 + "Micah Snyder (micasnyd)"
wrote:
Alternatively, you could switch your clamd.conf to use a TCP Socket.
Just make sure it isn't internet accessible.
Hi,
I'd have to look into this as the software talking to ClamAV expects a
local unix domain socket, I d
Hi,
I'm running ClamAV 0.100.1 (from pkg) under FreeBSD 11.2 amd64 -
occasionally it's being passed something it doesn't like, and 'clamd' is
dieing with a signal 11, i.e.
Sep 19 10:34:50 host clamd[855]: SelfCheck: Database status OK.
...
Sep 19 10:35:27 host kernel: pid 855 (clamd), uid 1
Hi,
From about 02:59 today (26/01) our we saw a pattern update, and we also
noticed freshclam logged, "DON'T PANIC! Read
http://www.clamav.net/documents/upgrading-clamav";
'freshclam' output shows:
main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder:
sigmgr)
daily.cld
--On 23 August 2006 14:50 -0400 Craig Green <[EMAIL PROTECTED]> wrote:
Karl Pielorz wrote:
We've narrowed this down a bit - and it doesn't look like it's just an
issue with 0.88.4 - we backed the server down to 0.88.1 and the same
thing happened...
As has been noted o
--On 23 August 2006 10:04 -0700 Chuck Swiger <[EMAIL PROTECTED]> wrote:
Clamd will grow as needed to handle any compressed files being passed to
it; perhaps someone is sending maliciously constructed archives which
require excessive resources to unpack and scan?
Hi,
Thanks for the reply..
Replying to my own posts is obviously not a good sign...
We've narrowed this down a bit - and it doesn't look like it's just an
issue with 0.88.4 - we backed the server down to 0.88.1 and the same thing
happened...
Looking back at the logs - clamd typically consumes around 40Mb / 36Mb of
me
Hi All,
We run ClamAV 0.88.4 under FreeBSD - we just recently moved from 0.88.1 (a
little old) to 0.88.4, and have noticed that the memory consumption of the
clamd process has gone through the roof.
I saw a couple of fairly recent posts on a similar thread - so we've got
fairly 'lax' proce
Hi All,
We're running ClamAV 0.80 under FreeBSD 4.10R, using the sendmail milter.
Just recently we've had clamd die a couple of times, syslog records:
"
Dec 8 16:52:34 devbox /kernel: pid 5453 (clamd), uid 106: exited on signal
4
Dec 8 16:52:34 devbox clamav-milter: clamfi_eom: read nothing from
14 matches
Mail list logo
