On 2018-11-19 16:42:35 [-0800], Adam Lambert wrote:
> Ah, so I think you may have the winner. I set my temp directory to be
> something other than /tmp, and turned ClamAV back on, and it's been running
> for about an hour now with no obvious ill effects. I will report back if
> something else
On Mon, 19 Nov 2018 16:42:35 -0800 Adam Lambert wrote:
> Ah, so I think you may have the winner. I set my temp directory to be
> something other than /tmp, and turned ClamAV back on, and it's been running
> for about an hour now with no obvious ill effects. I will report back if
> something
Ah, so I think you may have the winner. I set my temp directory to be
something other than /tmp, and turned ClamAV back on, and it's been running
for about an hour now with no obvious ill effects. I will report back if
something else crops up, but I think this may solve it.
Thank you!
On
On 2018-11-19 21:01:07 [+0100], To Adam Lambert wrote:
> On 2018-11-12 10:17:32 [-0800], Adam Lambert wrote:
> > I believe I already supplied all that way back when I opened up this bug
> > report. But for reference, here it is again:
>
> I tried it back then with no luck. Thanks for the info.
On 2018-11-12 10:17:32 [-0800], Adam Lambert wrote:
> I believe I already supplied all that way back when I opened up this bug
> report. But for reference, here it is again:
I tried it back then with no luck. Thanks for the info. I will try to
reproduce this asap and get back to you.
Sebastian
I believe I already supplied all that way back when I opened up this bug
report. But for reference, here it is again:
1) Standard kernel boot params that come after a vanilla Debian install
(ie: I have not modified them).
2) Config file is below. All I "do" is 'service clamav-daemon start'
On 2018-11-08 15:15:57 [-0800], Adam Lambert wrote:
> What do you need me to do to provide debug info on this?
I would like to reproduce this. I would need the clamd.conf, kernel
command line if something non-standard and what it is you do.
If I can reproduce this on my Stretch VM then I try to
I apologize for weighing in late, I saw earlier in the thread that Marc
Dequènes reported reproducing it and assumed that would be sufficient.
No, this is not solved. I just apt upgrade'd to the latest version
(0.100.2+dfsg-0+deb9u1),
and again, within seconds, the system went down hard.
What
On 2018-11-03 17:11:07 [+], Scott Kitterman wrote:
> Does anyone still have this problem with 0.100.2? It's been out awhile and
> this bug has gone quiet.
I would suggest to close it. I never had any luck to reproduce it. It
may or may not be a problem but without any additional help to get
On Wed, 25 Jul 2018 22:03:46 +0200 Sebastian Andrzej Siewior
wrote:
> On 2018-07-25 12:14:17 [+0900], Marc Dequènes (duck) wrote:
> > Quack,
> >
> > I did not try to switch on ScanOnAccess on my production system, but with my
> > configuration, which is not that different, I do not have the
On 2018-08-05 13:18:26 [+0200], To Marc Dequènes wrote:
> I didn't manage to reproduce it yet. My plan was to to gather enough
this is still the case.
> informations to reproduce it and forward it upstream.
> Is there anything wrong / different with my setup compared to your?
> Maybe different
On 2018-07-27 23:56:53 [+0200], To Marc Dequènes wrote:
> On 2018-07-25 22:03:46 [+0200], To Marc Dequènes wrote:
> > > I just tried loading Adam's configuration on another system to test the
> > > ScanOnAccess, copied a clamav test file in one of the protected directory
> > > and hit the problem.
On 2018-07-25 22:03:46 [+0200], To Marc Dequènes wrote:
> > I just tried loading Adam's configuration on another system to test the
> > ScanOnAccess, copied a clamav test file in one of the protected directory
> > and hit the problem. After that the whole machine becomes totally
> > unresponsive
On 2018-07-25 12:14:17 [+0900], Marc Dequènes (duck) wrote:
> Quack,
>
> I did not try to switch on ScanOnAccess on my production system, but with my
> configuration, which is not that different, I do not have the problem.
>
> I just tried loading Adam's configuration on another system to test
On Tue, 24 Jul 2018 21:51:21 +0200
Sebastian Andrzej Siewior wrote:
> > That looks like a different issue. Does it still happen if you
> > remove clamav-unofficial-sigs?
>
> This is #902899, the strace shows
>
> |clamd: yara_exec.c:177: yr_execu
>
> so were done here :)
Yep, that did it :)
Quack,
On 2018-07-24 15:18, Sebastian Andrzej Siewior wrote:
On 2018-07-23 17:54:44 [+0900], Marc Dequènes wrote:
Quack,
Hi,
I just upgraded and cannot reproduce this problem. I'm not using the
ScanOnAccess feature.
just to confirm: you can not reproduce the problem.
I did not try to
On 2018-07-24 11:06:01 [+], Scott Kitterman wrote:
> On July 24, 2018 10:42:44 AM UTC, richard lucassen
> wrote:
> >http://tmp.xaq.nl/clamd.strace
…
> >plus a vanilla install of clamav-unofficial-sigs.
>
> That looks like a different issue. Does it still happen if you remove
>
On July 24, 2018 10:42:44 AM UTC, richard lucassen
wrote:
>On Tue, 24 Jul 2018 08:19:15 +0200
>Sebastian Andrzej Siewior wrote:
>
>> Is the kernel complaining about something like in the other report
>> where it claimed something about a deadlock?
>
>No, no words like fanotify, deadlock or
On Tue, 24 Jul 2018 08:19:15 +0200
Sebastian Andrzej Siewior wrote:
> Is the kernel complaining about something like in the other report
> where it claimed something about a deadlock?
No, no words like fanotify, deadlock or blocked appear in the logs.
I blocked and upgraded one of the
On 2018-07-23 17:54:44 [+0900], Marc Dequènes wrote:
> Quack,
Hi,
> I just upgraded and cannot reproduce this problem. I'm not using the
> ScanOnAccess feature.
just to confirm: you can not reproduce the problem.
> Follows collected config info.
> \_o<
Sebastian
On 2018-07-23 18:26:04 [+0200], Richard Lucassen wrote:
> Same here (6 Postfix front-end servers), non-systemd, non-GUI system
> running Debian Stretch. Downgrading to 0.99 is a workaround.
> ScanOnAccess is set to false.
Is the kernel complaining about something like in the other report where
it
Same here (6 Postfix front-end servers), non-systemd, non-GUI system
running Debian Stretch. Downgrading to 0.99 is a workaround.
ScanOnAccess is set to false.
R.
--
___
It is better to remain silent and be thought a fool, than to
Quack,
I just upgraded and cannot reproduce this problem. I'm not using the
ScanOnAccess feature.
Follows collected config info.
\_o<
-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav
Config file: clamd.conf
---
BlockMax
This is my primary workstation, which is not very convenient to test with
at this time (I lost 3 hours of work already getting it stabilized again).
Could you perhaps use my config on one of your test systems and try to
duplicate first? If you can not duplicate, I will be willing to put some
more
On 2018-07-19 13:38:04 [-0700], Adam Lambert wrote:
> clamd (28514): Using fanotify permission checks may lead to deadlock;
> tainting kernel
> and shortly thereafter
This seems to become true.
> INFO: task clamd:28512 blocked for more than 120 seconds.
That is deadlock that happens.
> I
Package: clamav-daemon
Version: 0.100.0+dfsg-0+deb9u2
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
After a recent apt upgrade, within a few minutes, my system started locking up.
A reboot would buy me about 2 minutes of working time before it locked up again.
I
26 matches
Mail list logo
