[clamav-users] clamonacc behaviour - update 3 - FINAL

Frans de Boer frans at fransdb.nl
Tue Oct 15 16:17:38 EDT 2019


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.



More information about the clamav-users mailing list