Mailing List Archive

[clamav-users] clamonacc behaviour
LS,

Below is a piece of output listing, which ends with errors:

clamonacc --config-file=/etc/clamav/clamd.conf --foreground --verbose
ClamClient: client setup for continuous scanning
Clamonacc: daemon is local
ClamFanotif: kernel-level blocking feature disabled ...
ClamFanotif: max file size limited to 10485760 bytes
Clamonacc: beginning event loops
ClamFanotif: starting fanotify event loop with process id (17850) ...
ClamInotif: starting inotify event loop ...
ClamInotif: dynamically determining directory hierarchy...
ClamScanQueue: initializing event queue consumer ... (20) threads in
thread pool
ClamScanQueue: waiting to consume events ...
ClamInotif: watching '/mnt/raidarray/fdb-data' (and all sub-directories)
ClamInotif: watching '/mnt/raidarray/sdb-data' (and all sub-directories)
ClamInotif: watching '/mnt/raidarray/shared-data' (and all sub-directories)
ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/bin/BOINC' (and
all sub-directories)
ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.thunderbird'
(and all sub-directories)
ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.mozilla' (and
all sub-directories)
ERROR: ClamInotif: could not watch path '/mnt/raidarray/fdb-data', No
such file or directory
ClamInotif: extra scanning on inotify events enabled
ClamInotif: DELETE - removing
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/mips
from
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
with wd:27785
ClamInotif: CREATE - adding
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
to
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
with wd:27785
ClamInotif: attempting to feed consumer queue
ClamWorker: handling inotify event ...
ClamWorker: performing (extra) scanning on directory
'/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k'
ClamInotif: CREATE - adding
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
to
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
with wd:30908
ClamInotif: attempting to feed consumer queue
ClamInotif: CREATE - adding
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
to
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
with wd:30909
ClamInotif: attempting to feed consumer queue
ClamWorker: handling inotify event ...
ClamWorker: performing (extra) scanning on directory
'/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools'
ClamWorker: handling inotify event ...
ClamWorker: performing (extra) scanning on directory
'/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga'
ClamInotif: CREATE - adding
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS
to
/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
with wd:30910
ClamInotif: attempting to feed consumer queue
ClamWorker: handling inotify event ...
ClamWorker: performing (extra) scanning on directory
'/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS'
ERROR: Can't send to clamd: Bad address
ClamClient: connection could not be established ... return code 0
ClamMisc: internal issue (client failed to scan)
ERROR: Can't send to clamd: Bad address
ClamClient: connection could not be established ... return code 0
ClamMisc: internal issue (client failed to scan)

...at least, it looks like that. It starts with a "Bad address" error,
followed by two messages of which one state that it's internal issue.

Anybody seen this before?

--- Frans.


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: [clamav-users] clamonacc behaviour - update [ In reply to ]
On 13-10-2019 20:29, Frans de Boer wrote:
> LS,
>
> Below is a piece of output listing, which ends with errors:
>
> clamonacc --config-file=/etc/clamav/clamd.conf --foreground --verbose
> ClamClient: client setup for continuous scanning
> Clamonacc: daemon is local
> ClamFanotif: kernel-level blocking feature disabled ...
> ClamFanotif: max file size limited to 10485760 bytes
> Clamonacc: beginning event loops
> ClamFanotif: starting fanotify event loop with process id (17850) ...
> ClamInotif: starting inotify event loop ...
> ClamInotif: dynamically determining directory hierarchy...
> ClamScanQueue: initializing event queue consumer ... (20) threads in
> thread pool
> ClamScanQueue: waiting to consume events ...
> ClamInotif: watching '/mnt/raidarray/fdb-data' (and all sub-directories)
> ClamInotif: watching '/mnt/raidarray/sdb-data' (and all sub-directories)
> ClamInotif: watching '/mnt/raidarray/shared-data' (and all
> sub-directories)
> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/bin/BOINC'
> (and all sub-directories)
> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.thunderbird'
> (and all sub-directories)
> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.mozilla' (and
> all sub-directories)
> ERROR: ClamInotif: could not watch path '/mnt/raidarray/fdb-data', No
> such file or directory
> ClamInotif: extra scanning on inotify events enabled
> ClamInotif: DELETE - removing
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/mips
> from
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
> with wd:27785
> ClamInotif: CREATE - adding
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
> to
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
> with wd:27785
> ClamInotif: attempting to feed consumer queue
> ClamWorker: handling inotify event ...
> ClamWorker: performing (extra) scanning on directory
> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k'
> ClamInotif: CREATE - adding
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
> to
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
> with wd:30908
> ClamInotif: attempting to feed consumer queue
> ClamInotif: CREATE - adding
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
> to
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
> with wd:30909
> ClamInotif: attempting to feed consumer queue
> ClamWorker: handling inotify event ...
> ClamWorker: performing (extra) scanning on directory
> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools'
> ClamWorker: handling inotify event ...
> ClamWorker: performing (extra) scanning on directory
> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga'
> ClamInotif: CREATE - adding
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS
> to
> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
> with wd:30910
> ClamInotif: attempting to feed consumer queue
> ClamWorker: handling inotify event ...
> ClamWorker: performing (extra) scanning on directory
> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS'
> ERROR: Can't send to clamd: Bad address
> ClamClient: connection could not be established ... return code 0
> ClamMisc: internal issue (client failed to scan)
> ERROR: Can't send to clamd: Bad address
> ClamClient: connection could not be established ... return code 0
> ClamMisc: internal issue (client failed to scan)
>
> ...at least, it looks like that. It starts with a "Bad address" error,
> followed by two messages of which one state that it's internal issue.
>
> Anybody seen this before?
>
> --- Frans.

The "Bad address" message is generated because a file has been created,
but before it can be act upon, the same file is already removed. I have
scripts running every 4 hours, which scan for updates on GNU, Kernel
etc. Thereby creating small files in the designated directories. After
processing, these files are removed too. Which is causing the ERROR
reports. Rightfully so, but annoying.

Now, I run clamonacc with the --foreground switch, filtering these
messages and what is left, writing it into the log file.

--- Frans


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: [clamav-users] clamonacc behaviour - update 2 [ In reply to ]
On 15-10-2019 13:05, Frans de Boer wrote:
> On 13-10-2019 20:29, Frans de Boer wrote:
>> LS,
>>
>> Below is a piece of output listing, which ends with errors:
>>
>> clamonacc --config-file=/etc/clamav/clamd.conf --foreground --verbose
>> ClamClient: client setup for continuous scanning
>> Clamonacc: daemon is local
>> ClamFanotif: kernel-level blocking feature disabled ...
>> ClamFanotif: max file size limited to 10485760 bytes
>> Clamonacc: beginning event loops
>> ClamFanotif: starting fanotify event loop with process id (17850) ...
>> ClamInotif: starting inotify event loop ...
>> ClamInotif: dynamically determining directory hierarchy...
>> ClamScanQueue: initializing event queue consumer ... (20) threads in
>> thread pool
>> ClamScanQueue: waiting to consume events ...
>> ClamInotif: watching '/mnt/raidarray/fdb-data' (and all sub-directories)
>> ClamInotif: watching '/mnt/raidarray/sdb-data' (and all sub-directories)
>> ClamInotif: watching '/mnt/raidarray/shared-data' (and all
>> sub-directories)
>> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/bin/BOINC'
>> (and all sub-directories)
>> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.thunderbird'
>> (and all sub-directories)
>> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.mozilla'
>> (and all sub-directories)
>> ERROR: ClamInotif: could not watch path '/mnt/raidarray/fdb-data', No
>> such file or directory
>> ClamInotif: extra scanning on inotify events enabled
>> ClamInotif: DELETE - removing
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/mips
>> from
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
>> with wd:27785
>> ClamInotif: CREATE - adding
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
>> to
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
>> with wd:27785
>> ClamInotif: attempting to feed consumer queue
>> ClamWorker: handling inotify event ...
>> ClamWorker: performing (extra) scanning on directory
>> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k'
>> ClamInotif: CREATE - adding
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
>> to
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
>> with wd:30908
>> ClamInotif: attempting to feed consumer queue
>> ClamInotif: CREATE - adding
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
>> to
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
>> with wd:30909
>> ClamInotif: attempting to feed consumer queue
>> ClamWorker: handling inotify event ...
>> ClamWorker: performing (extra) scanning on directory
>> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools'
>> ClamWorker: handling inotify event ...
>> ClamWorker: performing (extra) scanning on directory
>> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga'
>> ClamInotif: CREATE - adding
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS
>> to
>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
>> with wd:30910
>> ClamInotif: attempting to feed consumer queue
>> ClamWorker: handling inotify event ...
>> ClamWorker: performing (extra) scanning on directory
>> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS'
>> ERROR: Can't send to clamd: Bad address
>> ClamClient: connection could not be established ... return code 0
>> ClamMisc: internal issue (client failed to scan)
>> ERROR: Can't send to clamd: Bad address
>> ClamClient: connection could not be established ... return code 0
>> ClamMisc: internal issue (client failed to scan)
>>
>> ...at least, it looks like that. It starts with a "Bad address"
>> error, followed by two messages of which one state that it's internal
>> issue.
>>
>> Anybody seen this before?
>>
>> --- Frans.
>
> The "Bad address" message is generated because a file has been
> created, but before it can be act upon, the same file is already
> removed. I have scripts running every 4 hours, which scan for updates
> on GNU, Kernel etc. Thereby creating small files in the designated
> directories. After processing, these files are removed too. Which is
> causing the ERROR reports. Rightfully so, but annoying.
>
> Now, I run clamonacc with the --foreground switch, filtering these
> messages and what is left, writing it into the log file.
>
> --- Frans

As it turns out: I have to suppress all ClamMisc: messages. That leaves
the messages generated when a directory has been created, clamonacc
picks up that action, the directory is removed by the primary process
before clamd has a change to process the fd. It generates the "Access
Denied" message.

Ok, I can filter that out too "sed '/regexp/d'", but I have never seen
these messages in the 0.101 series.
So, separating the on-access code from clamd might look good, but
generates all kind of unwanted messages. Short of altering the source
code itself, it might be helpful to allow some user control over the
generated messages. In fact, I want to see only messages dealing with
malware or serious software errors in the log files.

--- Frans.


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: [clamav-users] clamonacc behaviour - update 2 [ In reply to ]
Hi there,

On Tue, 15 Oct 2019, Frans de Boer wrote:

> ... separating the on-access code from clamd might look good, but generates
> all kind of unwanted messages. Short of altering the source code itself, it
> might be helpful to allow some user control over the generated messages. In
> fact, I want to see only messages dealing with malware or serious software
> errors in the log files.

Search for 'legend:' in shared/output.c for a very brief description of the
logging facility in ClamAV.

Can I suggest that you also look at syslog-ng?

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: [clamav-users] clamonacc behaviour - update 3 - FINAL [ In reply to ]
On 15-10-2019 21:00, Frans de Boer wrote:
> On 15-10-2019 13:05, Frans de Boer wrote:
>> On 13-10-2019 20:29, Frans de Boer wrote:
>>> LS,
>>>
>>> Below is a piece of output listing, which ends with errors:
>>>
>>> clamonacc --config-file=/etc/clamav/clamd.conf --foreground --verbose
>>> ClamClient: client setup for continuous scanning
>>> Clamonacc: daemon is local
>>> ClamFanotif: kernel-level blocking feature disabled ...
>>> ClamFanotif: max file size limited to 10485760 bytes
>>> Clamonacc: beginning event loops
>>> ClamFanotif: starting fanotify event loop with process id (17850) ...
>>> ClamInotif: starting inotify event loop ...
>>> ClamInotif: dynamically determining directory hierarchy...
>>> ClamScanQueue: initializing event queue consumer ... (20) threads in
>>> thread pool
>>> ClamScanQueue: waiting to consume events ...
>>> ClamInotif: watching '/mnt/raidarray/fdb-data' (and all
>>> sub-directories)
>>> ClamInotif: watching '/mnt/raidarray/sdb-data' (and all
>>> sub-directories)
>>> ClamInotif: watching '/mnt/raidarray/shared-data' (and all
>>> sub-directories)
>>> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/bin/BOINC'
>>> (and all sub-directories)
>>> ClamInotif: excluding
>>> '/mnt/raidarray/fdb-data/fdb-home/.thunderbird' (and all
>>> sub-directories)
>>> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.mozilla'
>>> (and all sub-directories)
>>> ERROR: ClamInotif: could not watch path '/mnt/raidarray/fdb-data',
>>> No such file or directory
>>> ClamInotif: extra scanning on inotify events enabled
>>> ClamInotif: DELETE - removing
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/mips
>>> from
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
>>> with wd:27785
>>> ClamInotif: CREATE - adding
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
>>> to
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
>>> with wd:27785
>>> ClamInotif: attempting to feed consumer queue
>>> ClamWorker: handling inotify event ...
>>> ClamWorker: performing (extra) scanning on directory
>>> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k'
>>> ClamInotif: CREATE - adding
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
>>> to
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
>>> with wd:30908
>>> ClamInotif: attempting to feed consumer queue
>>> ClamInotif: CREATE - adding
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
>>> to
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
>>> with wd:30909
>>> ClamInotif: attempting to feed consumer queue
>>> ClamWorker: handling inotify event ...
>>> ClamWorker: performing (extra) scanning on directory
>>> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools'
>>> ClamWorker: handling inotify event ...
>>> ClamWorker: performing (extra) scanning on directory
>>> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga'
>>> ClamInotif: CREATE - adding
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS
>>> to
>>> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
>>> with wd:30910
>>> ClamInotif: attempting to feed consumer queue
>>> ClamWorker: handling inotify event ...
>>> ClamWorker: performing (extra) scanning on directory
>>> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS'
>>> ERROR: Can't send to clamd: Bad address
>>> ClamClient: connection could not be established ... return code 0
>>> ClamMisc: internal issue (client failed to scan)
>>> ERROR: Can't send to clamd: Bad address
>>> ClamClient: connection could not be established ... return code 0
>>> ClamMisc: internal issue (client failed to scan)
>>>
>>> ...at least, it looks like that. It starts with a "Bad address"
>>> error, followed by two messages of which one state that it's
>>> internal issue.
>>>
>>> Anybody seen this before?
>>>
>>> --- Frans.
>>
>> The "Bad address" message is generated because a file has been
>> created, but before it can be act upon, the same file is already
>> removed. I have scripts running every 4 hours, which scan for updates
>> on GNU, Kernel etc. Thereby creating small files in the designated
>> directories. After processing, these files are removed too. Which is
>> causing the ERROR reports. Rightfully so, but annoying.
>>
>> Now, I run clamonacc with the --foreground switch, filtering these
>> messages and what is left, writing it into the log file.
>>
>> --- Frans
>
> As it turns out: I have to suppress all ClamMisc: messages. That
> leaves the messages generated when a directory has been created,
> clamonacc picks up that action, the directory is removed by the
> primary process before clamd has a change to process the fd. It
> generates the "Access Denied" message.
>
> Ok, I can filter that out too "sed '/regexp/d'", but I have never seen
> these messages in the 0.101 series.
> So, separating the on-access code from clamd might look good, but
> generates all kind of unwanted messages. Short of altering the source
> code itself, it might be helpful to allow some user control over the
> generated messages. In fact, I want to see only messages dealing with
> malware or serious software errors in the log files.
>
> --- Frans.

I found out that it's not possible to pipe output to sed when using a
.service file. Also, just like using a common bash script or using a
.service file,  the output of clamd is only about client disconnections,
cluttering the clamd log file.

It's enough, I switch back to 0.101. 0.102 is not mature enough and I
can spent my time better.

--- Frans.


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: [clamav-users] clamonacc behaviour - update 2 [ In reply to ]
On 16-10-2019 18:36, Mickey Sola (micksola) wrote:
> >>> In fact, I want to see only messages dealing with
> malware or serious software errors in the log files.
>
> If you run without the --verbose option, you get exactly that.
> --verbose was primarily meant for devs and debugging purposes. A
> common piece of feedback we'd received was that users were only really
> interested in malware detection and errors in their logs, thus we
> tried to cater to those needs when running clamonacc without
> --verbose. Beyond the "Bad address" issue, did you find clamonacc
> logging (without verbose) lacking what you needed above?
>
> That said and asked, I will switch the "Bad address" error to a
> warning so that it doesn't appear in non-verbose logs.
>
> On 2019-10-15 15:00:52-04:00 clamav-users wrote:
>
> On 15-10-2019 13:05, Frans de Boer wrote:
> > On 13-10-2019 20:29, Frans de Boer wrote:
> >> LS,
> >>
> >> Below is a piece of output listing, which ends with errors:
> >>
> >> clamonacc --config-file=/etc/clamav/clamd.conf --foreground --verbose
> >> ClamClient: client setup for continuous scanning
> >> Clamonacc: daemon is local
> >> ClamFanotif: kernel-level blocking feature disabled ...
> >> ClamFanotif: max file size limited to 10485760 bytes
> >> Clamonacc: beginning event loops
> >> ClamFanotif: starting fanotify event loop with process id (17850) ...
> >> ClamInotif: starting inotify event loop ...
> >> ClamInotif: dynamically determining directory hierarchy...
> >> ClamScanQueue: initializing event queue consumer ... (20) threads in
> >> thread pool
> >> ClamScanQueue: waiting to consume events ...
> >> ClamInotif: watching '/mnt/raidarray/fdb-data' (and all sub-directories)
> >> ClamInotif: watching '/mnt/raidarray/sdb-data' (and all sub-directories)
> >> ClamInotif: watching '/mnt/raidarray/shared-data' (and all
> >> sub-directories)
> >> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/bin/BOINC'
> >> (and all sub-directories)
> >> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.thunderbird'
> >> (and all sub-directories)
> >> ClamInotif: excluding '/mnt/raidarray/fdb-data/fdb-home/.mozilla'
> >> (and all sub-directories)
> >> ERROR: ClamInotif: could not watch path '/mnt/raidarray/fdb-data', No
> >> such file or directory
> >> ClamInotif: extra scanning on inotify events enabled
> >> ClamInotif: DELETE - removing
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/mips
> >> from
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
> >> with wd:27785
> >> ClamInotif: CREATE - adding
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
> >> to
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch
> >> with wd:27785
> >> ClamInotif: attempting to feed consumer queue
> >> ClamWorker: handling inotify event ...
> >> ClamWorker: performing (extra) scanning on directory
> >> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k'
> >> ClamInotif: CREATE - adding
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
> >> to
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k
> >> with wd:30908
> >> ClamInotif: attempting to feed consumer queue
> >> ClamInotif: CREATE - adding
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
> >> to
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools
> >> with wd:30909
> >> ClamInotif: attempting to feed consumer queue
> >> ClamWorker: handling inotify event ...
> >> ClamWorker: performing (extra) scanning on directory
> >> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools'
> >> ClamWorker: handling inotify event ...
> >> ClamWorker: performing (extra) scanning on directory
> >> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga'
> >> ClamInotif: CREATE - adding
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS
> >> to
> >> /mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga
> >> with wd:30910
> >> ClamInotif: attempting to feed consumer queue
> >> ClamWorker: handling inotify event ...
> >> ClamWorker: performing (extra) scanning on directory
> >> '/mnt/raidarray/fdb-data/program_repository/general_sources/linux/kernel/people/marcelo/linux-2.4/arch/m68k/tools/amiga/SCCS'
> >> ERROR: Can't send to clamd: Bad address
> >> ClamClient: connection could not be established ... return code 0
> >> ClamMisc: internal issue (client failed to scan)
> >> ERROR: Can't send to clamd: Bad address
> >> ClamClient: connection could not be established ... return code 0
> >> ClamMisc: internal issue (client failed to scan)
> >>
> >> ...at least, it looks like that. It starts with a "Bad address"
> >> error, followed by two messages of which one state that it's internal
> >> issue.
> >>
> >> Anybody seen this before?
> >>
> >> --- Frans.
> >
> > The "Bad address" message is generated because a file has been
> > created, but before it can be act upon, the same file is already
> > removed. I have scripts running every 4 hours, which scan for updates
> > on GNU, Kernel etc. Thereby creating small files in the designated
> > directories. After processing, these files are removed too. Which is
> > causing the ERROR reports. Rightfully so, but annoying.
> >
> > Now, I run clamonacc with the --foreground switch, filtering these
> > messages and what is left, writing it into the log file.
> >
> > --- Frans
>
> As it turns out: I have to suppress all ClamMisc: messages. That leaves
> the messages generated when a directory has been created, clamonacc
> picks up that action, the directory is removed by the primary process
> before clamd has a change to process the fd. It generates the "Access
> Denied" message.
>
> Ok, I can filter that out too "sed '/regexp/d'", but I have never seen
> these messages in the 0.101 series.
> So, separating the on-access code from clamd might look good, but
> generates all kind of unwanted messages. Short of altering the source
> code itself, it might be helpful to allow some user control over the
> generated messages. In fact, I want to see only messages dealing with
> malware or serious software errors in the log files.
>
> --- Frans.
>
@Mickey, Yes I know that in the first example I used the verbose switch.
I also found out later that without the verbose switch things where more
relaxed, but the 'Bad address' errors keep popping up. I suppressed that
too, only to found out that clamd is spawning non-functional messages.
So, even if you reclassify ClamNotify as being a warning only - you
should otherwise call it ClamError -, the issue with clamd remains.

There was an early reply in this thread of using syslog-ng. Now I output
messages to each individual file, while not using syslog. It has been a
long time ago since I looked into syslog-ng, but see indeed an answer in
there. So, I'll switch back to syslog and add filters to syslog-ng as
well as different output targets.

I now think that syslog-ng is indeed a viable solution to get only
functional messages, albeit it takes some work to develop the filters
(although it's syntax is very clean). Unless of course someone else has
developed these filters in the meantime and want to share them with the
community/me.

--- Frans.