applied this
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5629164.html
this one was already applied:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1582767
This was the result (still no successful update) but looks like one of the
apparmor "denials" have disappeared:
On Wednesday 04 September 2019, Sergey wrote:
> Since some time there has been a noticeable increase a launch time.
> Startup with all databases takes about 220 seconds now. Startup
> without daily.cld takes 12 seconds. What's happened with daily.cld?
freshclam downloaded "daily.cvd" in next
Hello.
Since some time there has been a noticeable increase a launch time.
Startup with all databases takes about 220 seconds now. Startup
without daily.cld takes 12 seconds. What's happened with daily.cld?
Thu Jul 18 12:36:51 2019 -> clamd daemon 0.101.2 (OS: linux-gnu, ARCH: x86_64,
CPU:
This looks promising to troubleshoot.
Sent from my iPhone
> On Sep 4, 2019, at 03:01, Birger Birger via clamav-users
> wrote:
>
> Sep 4 08:40:01 zentyal kernel: [345190.998397] audit: type=1400
> audit(1567579201.044:83): apparmor="DENIED" operation="connect"
>
Hi Mark. Thanks for the reply.
I think your guess is correct. Assuming my OnAccess errors directly
correlate to the auditd info below[1][2], this appears to be a bug in
the AppArmor profiles included with the Ubuntu packages "clamav-daemon"
and "clamav-freshclam":
jblaine@ub18test:~$ sudo dpkg
Am 2019-09-01 19:30, schrieb Joel Esler (jesler) via clamav-users:
Alright. I think we’ve beat the proverbial dead horse here. The devs
know this is a request and they will get it into their dev queue for
examination.
I saw that clamd use just one core at a time to load the databases.
top -
Hi Jeff,
Looks like Apparmor may be stepping in and preventing access. Have you
checked that Apparmor has been changed to give clamd the required
permissions ?
Regards
Mark.
On 03/09/2019 22:01, Jeff Blaine via clamav-users wrote:
Hello all,
I'm experiencing something odd on
The database load process reads signatures and uses the data to populate a
couple of pseudo-tries (https://en.wikipedia.org/wiki/Trie). The tries
themselves could only be modified by a single thread at a time, with a mutex
around each trie. There might be some performance to be gained by
Hi Joel,
On Wed, 4 Sep 2019, G.W. Haywood wrote:
... some junk mails aren't being detected by clamd, even though
there are valid signatures in the database that are supposed to
match them.
I guess you have the two files which I attached. You can see below
what happens when I scan them using
Hi there,
On 9/4/19, 1:40 PM, Thomas Barth via wrote:
> Why not using half of the cores to also reduce the loading time? Many
> years ago when I used eMule for downloading big files, I was so
> fascinated by the download mechanism: one big file, many download
> sources to get the file
10 matches
Mail list logo
