Bill Landry wrote:
> Dennis Peterson wrote:
>> Bill Landry wrote:
>>> Dennis Peterson wrote:
Bill Landry wrote:
> Dennis Peterson wrote:
>> I don't know when clamd will self-check. Do you?
> That can be disable in clamd.conf and then reloads scripted:
>
> SelfCheck 0
>
Dennis Peterson wrote:
> Bill Landry wrote:
>> Dennis Peterson wrote:
>>> Bill Landry wrote:
Dennis Peterson wrote:
> I don't know when clamd will self-check. Do you?
That can be disable in clamd.conf and then reloads scripted:
SelfCheck 0
Then you will see in the
Bill Landry wrote:
> Dennis Peterson wrote:
>> Bill Landry wrote:
>>> Dennis Peterson wrote:
I don't know when clamd will self-check. Do you?
>>> That can be disable in clamd.conf and then reloads scripted:
>>>
>>> SelfCheck 0
>>>
>>> Then you will see in the clamd.log on restart:
>>>
>>> Wed
Dennis Peterson wrote:
> Bill Landry wrote:
>> Dennis Peterson wrote:
>
>>> I don't know when clamd will self-check. Do you?
>> That can be disable in clamd.conf and then reloads scripted:
>>
>> SelfCheck 0
>>
>> Then you will see in the clamd.log on restart:
>>
>> Wed Mar 4 20:11:41 2009 -> Self
Bill Landry wrote:
> Dennis Peterson wrote:
>> I don't know when clamd will self-check. Do you?
>
> That can be disable in clamd.conf and then reloads scripted:
>
> SelfCheck 0
>
> Then you will see in the clamd.log on restart:
>
> Wed Mar 4 20:11:41 2009 -> Self checking disabled.
Not on my
Dennis Peterson wrote:
> Bill Landry wrote:
>> Dennis Peterson wrote:
>>
>>> It doesn't matter - I use rsync in these situations because all moves are
>>> atomic, all the time.
>>>
>>> I have a mail server farm that includes production and dev systems, and NFS
>>> is
>>> used to access a large Z
Bill Landry wrote:
> Dennis Peterson wrote:
>
>> It doesn't matter - I use rsync in these situations because all moves are
>> atomic, all the time.
>>
>> I have a mail server farm that includes production and dev systems, and NFS
>> is
>> used to access a large ZFS file system to redistribute t
Dennis Peterson wrote:
> It doesn't matter - I use rsync in these situations because all moves are
> atomic, all the time.
>
> I have a mail server farm that includes production and dev systems, and NFS
> is
> used to access a large ZFS file system to redistribute this stuff.
>
> There is ano
Bill Landry wrote:
> Dennis Peterson wrote:
>> Bill Landry wrote:
>>
>>> I have read that standards since POSIX.1-1988 onwards have imposed
>>> atomicity requirements on rename (mv) that effectively require it to be
>>> a system call. The Open Group Base Specifications Issue 7 states:
>>>
>>> "Thi
Dennis Peterson wrote:
> Bill Landry wrote:
>
>> I have read that standards since POSIX.1-1988 onwards have imposed
>> atomicity requirements on rename (mv) that effectively require it to be
>> a system call. The Open Group Base Specifications Issue 7 states:
>>
>> "This rename() function is equi
Bill Landry wrote:
> I have read that standards since POSIX.1-1988 onwards have imposed
> atomicity requirements on rename (mv) that effectively require it to be
> a system call. The Open Group Base Specifications Issue 7 states:
>
> "This rename() function is equivalent for regular files to tha
Dennis Peterson wrote:
> Steve Basford wrote:
>
>> Gut feeling is that it's not a signature problem, more timing perhaps
>> caused by the increase in the number of signatures being reloaded,
>> and the interaction between freshclam, the RELOAD/USR2 command (used by
>> scripts) and clamd.
>>
>
>
Steve Basford wrote:
> Gut feeling is that it's not a signature problem, more timing perhaps
> caused by the increase in the number of signatures being reloaded,
> and the interaction between freshclam, the RELOAD/USR2 command (used by
> scripts) and clamd.
>
I don't have a problem here (yet,
I'm wondering why clamd first logs to the clamd.log that the Pid and
Socket files were removed, then reports errors that it could not unlink
the Pid and Socket files. This happens when the clamd service is
stopped (service clamd stop) on Fedora 10, with ClamAV version 0.95rc1.
Wed Mar 4 16:55:16
On Wed, 2009-03-04 at 19:36 +0200, Török Edwin wrote:
> As far as I understand the crash occurs when reloading the signatures
> (actually when freeing old signatures),
> but only if clamd had some load before (i.e. it doesn't crash just by
> reloading the signatures on a fresh clamd).
> That makes
Dennis Peterson wrote:
>
> I've rebuilt it with my standard script so it should behave again. Sorry for
> that distraction. I'll update the output of the time tests shortly.
>
> dp
I see in my previous post I gave myself an extra ghz in cpu speed - it's a
2gig,
not 3.
RedHat Linux, AMD Athl
Török Edwin wrote:
>
> Another thing to check is if mempool is enabled or not. It makes a 20%
> speed difference here.
> Try ./configure --disable-mempool to see if it is slower or not.
Strange ...
No changes 8-(
with --disable-mempool (I said DISABLE) :
# /usr/bin/time /opt/clamav/bin/clamsc
On Wed, Mar 4, 2009 at 9:54 PM, Jose-Marcio Martins da Cruz
wrote:
>> On a Solaris10/sparc box (UltraSPARC-IIi 440Mhz) it takes 18s.
>
> Hmmm, a T2000 is "slightly" better than your sparc box (a 10 years old
> Ultra 5 or Ultra 10 ?). But it doesn't seems too faster.
Those T2000's are not that fas
Török Edwin wrote:
> On 2009-03-04 23:18, Bill Landry wrote:
>> Török Edwin wrote:
>>
>>
>>> Was your clamd heavily loaded at that time?
>>> How long does this take:
>>> $ time clamscan /dev/null
>>>
>> Sorry to break in here, but I wanted to check how long my server would
>> take to load t
Dennis Peterson wrote:
> Steve Basford wrote:
>> Dennis Peterson wrote:
>>> Sparc Solaris 9, 500Mhz
>>> Known viruses: 563036
>>> Engine version: 0.95rc1
>>>
>>> LibClamAV Warning: *** Please update it as soon as possible.***
>>> Known viruses: 208929
>>> Engine version: 0.95rc1
>>>
>>
On 2009-03-04 22:54, Jose-Marcio Martins da Cruz wrote:
> Török Edwin wrote:
>
>> On 2009-03-04 21:53, Jose-Marcio Martins da Cruz wrote:
>>
>
>
>>>
>>>
>> Was your clamd heavily loaded at that time?
>>
>
> No. This is a test server. Absolutely no load. It seemed to me tha
On 2009-03-04 23:18, Bill Landry wrote:
> Török Edwin wrote:
>
>
>> Was your clamd heavily loaded at that time?
>> How long does this take:
>> $ time clamscan /dev/null
>>
>
> Sorry to break in here, but I wanted to check how long my server would
> take to load the signature databases with
Hello Török,
> > This is a delivery status notification from exa.billmerriam.com,
> > running the Courier mail server, version 0.54.1.
> Yes, I've just received one of these.
removed,
Best regards
--
Luca Gibelli (luca _at_ clamav.net) ClamAV, a GPL anti-virus toolkit
[Tel] +39 0187 185
Török Edwin wrote:
> Was your clamd heavily loaded at that time?
> How long does this take:
> $ time clamscan /dev/null
Sorry to break in here, but I wanted to check how long my server would
take to load the signature databases with v0.95rc1. However, this is
new to me:
clamscan /dev/null
LibCl
Steve Basford wrote:
>
> Dennis Peterson wrote:
>> Sparc Solaris 9, 500Mhz
>> Known viruses: 563036
>> Engine version: 0.95rc1
>>
>> LibClamAV Warning: *** Please update it as soon as possible.***
>> Known viruses: 208929
>> Engine version: 0.95rc1
>>
> Hi Dennis, 208929 vs 563036 sig
Steve Basford wrote:
>
> Dennis Peterson wrote:
>> Sparc Solaris 9, 500Mhz
>> Known viruses: 563036
>> Engine version: 0.95rc1
>>
>> LibClamAV Warning: *** Please update it as soon as possible.***
>> Known viruses: 208929
>> Engine version: 0.95rc1
>>
> Hi Dennis, 208929 vs 563036 sig
Dennis Peterson wrote:
> I understand that, but look at the title of this thread and the
> misunderstanding
> it implies (and spreads!). Help spread the word that it may have nothing to
> do
> with third-party sigs, and certainly not Sane Security in particular as the
> title suggests.
>
W
Dennis Peterson wrote:
> Sparc Solaris 9, 500Mhz
> Known viruses: 563036
> Engine version: 0.95rc1
>
> LibClamAV Warning: *** Please update it as soon as possible.***
> Known viruses: 208929
> Engine version: 0.95rc1
>
Hi Dennis, 208929 vs 563036 sigs? would that be the speed differ
Török Edwin wrote:
> On 2009-03-04 21:53, Jose-Marcio Martins da Cruz wrote:
>>
>
> Was your clamd heavily loaded at that time?
No. This is a test server. Absolutely no load. It seemed to me that it
was the message which triggered the database update.
top load is something like this :
load
Török Edwin wrote:
> On 2009-03-04 21:53, Jose-Marcio Martins da Cruz wrote:
>> Török Edwin wrote:
>>
>>> On 2009-03-04 19:44, Dennis Peterson wrote:
>>>
>>
>
>
Is there not a "nice" way to do this?
>>> 0.95rc1 does reload "nicer", in the sense that
On 2009-03-04 20:47, Dennis Peterson wrote:
> Anyone else receiving these NDRs?
>
> This is a delivery status notification from exa.billmerriam.com,
> running the Courier mail server, version 0.54.1.
>
Yes, I've just received one of these.
--Edwin
__
On 2009-03-04 21:53, Jose-Marcio Martins da Cruz wrote:
> Török Edwin wrote:
>
>> On 2009-03-04 19:44, Dennis Peterson wrote:
>>
>
>
>>> Is there not a "nice" way to do this?
>>>
>> 0.95rc1 does reload "nicer", in the sense that it accepts new
>> connection
Jose-Marcio Martins da Cruz wrote:
>
> So, if I understood, clamd accept connections while reloading the
> database, but handle them later.
>
> Am I wrong ?
I see the same kind of thing. I'm going to run some side-by-side tests on my
Solaris systems and my RedHat Linux system to see if there'
Török Edwin wrote:
> On 2009-03-04 19:44, Dennis Peterson wrote:
>>>
>> Is there not a "nice" way to do this?
>
> 0.95rc1 does reload "nicer", in the sense that it accepts new
> connections while reloading the DB.
> Reloading the database should take about a second. Using anything less
> th
Anyone else receiving these NDRs?
This is a delivery status notification from exa.billmerriam.com,
running the Courier mail server, version 0.54.1.
The original message was received on Wed, 04 Mar 2009 12:46:08 -0500
from localhost (localhost [127.0.0.1])
Török Edwin wrote:
> On 2009-03-04 19:44, Dennis Peterson wrote:
>> Török Edwin wrote:
>>
>>> On 2009-03-04 19:28, Dennis Peterson wrote:
>>>
>>
This can be tested by having some adventurous affected user run with only
third
party signatures - if it is that which is at f
On 2009-03-04 19:44, Dennis Peterson wrote:
> Török Edwin wrote:
>
>> On 2009-03-04 19:28, Dennis Peterson wrote:
>>
>
>
>>> This can be tested by having some adventurous affected user run with only
>>> third
>>> party signatures - if it is that which is at fault then clamd will contin
Török Edwin wrote:
> On 2009-03-04 19:28, Dennis Peterson wrote:
>>
>> This can be tested by having some adventurous affected user run with only
>> third
>> party signatures - if it is that which is at fault then clamd will continue
>> to
>> crash. Since this happens only while loading signatu
On 2009-03-04 19:28, Dennis Peterson wrote:
> Török Edwin wrote:
>
>> On 2009-03-04 17:49, Jorge Valdes wrote:
>>
>>> Because I run clamd via daemontools, whenever clamd crashes, its brought
>>> back to life within a few seconds and things hum along fine until the
>>> next crash, which is i
Török Edwin wrote:
> On 2009-03-04 17:49, Jorge Valdes wrote:
>> Because I run clamd via daemontools, whenever clamd crashes, its brought
>> back to life within a few seconds and things hum along fine until the
>> next crash, which is in my case, very unpredictable since I have gone
>> days without
On Wed, Mar 4, 2009 at 5:28 AM, Tomasz Kojm wrote:
> the DLP module will currently only look for SSNs in regular text files, we
> have plans for extending the detection to other formats in 0.96.
Does that mean it will not scan/detect CC/SSN's in the body of the
email? I've had this same problem,
On 2009-03-04 17:49, Jorge Valdes wrote:
> Because I run clamd via daemontools, whenever clamd crashes, its brought
> back to life within a few seconds and things hum along fine until the
> next crash, which is in my case, very unpredictable since I have gone
> days without a crash, and suddenly ha
I have been using clamav for a while and have been keeping up with the
unresolved crashes aparently from the SaneSecurity definitions (which by
the way I think are great). I stumbled upon this while checking my clamd
server logwatch report:
*** glibc detected *** /usr/local/sbin/clamd: free(): in
On Wed, 4 Mar 2009 06:06:43 -0700
scuttled monkey wrote:
> Hello,
>
> The dlp module doesn't seem to be working for me. I was wondering if anyone
> is using it and has run into the same problem. When I send email with
> embedded SSNs or a word document with SSNs embedded the mail the email is
>
Hello,
The dlp module doesn't seem to be working for me. I was wondering if anyone
is using it and has run into the same problem. When I send email with
embedded SSNs or a word document with SSNs embedded the mail the email is
scanned and sent on its way to the receiver of the email and is not
qua
45 matches
Mail list logo
