Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
Hi Jim, On 06.06.2014 02:58, Jim Barber wrote: After reading the discussion on the upstream bug report, it looks like perhaps these error messages in the logs were relevant after all... - ERROR: ScanOnAccess: fanotify_init failed: Operation not permitted - ScanOnAccess: clamd must be started by root Well, these caused the hang more or less indirectly. The problem was not the content these messages convey, but rather that during logging of these messages, the thread doing so got killed, leaving the logg_mutex locked. Is ScanOnAccess something that is toggled depending on how you answer dpkg configuration questions? Or is it something I manually need to change in the /etc/clamav/clamd.conf ? Run 'sudo dpkg-reconfigure clamav-daemon' and, when asked 'Do you want to enable on-access scanning?' answer with no. I didn't see a question relevant to it at installation time. There are too many configuration options, so they are not asked at installation time, only when you run dpkg-reconfigure. I have done a fresh install of clamav-daemon on a virtual machine and ScanOnAccess is set to false. To my knowledge I never manually set it to true on the system that I have the issue with. So I can only guess that it was enabled in one of the older clamav-daemon packages and subsequent upgrades have preserved the setting? I've been using this Debian system for many years (I think since around 2009) Either that, or I set it so long ago I just can't remember doing it. clamav 0.98.1+dfsg-3, which introduced these settings, created bogus configurations. Upgrading from that version should have fixed these problems, but apparently it sometimes didn't. To get the default settings, you can just purge clamav-daemon and clamav-freshclam and then install them again. Thanks for all your help resolving the issue Andreas. Thanks for reporting this bug. I look forward to the fixed packages appearing in the Debian mirror. There will be a new upload, once clamav 0.98.4 is released. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
Control: tags -1 fixed-upstream pending Hi Jim, upstream fixed the problem and I have backported the fix for Debian, so that it will be included in the next upload. Until then just disable ScanOnAccess to work around the problem. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
On 6/06/2014 2:24 AM, Andreas Cadhalpun wrote: Control: tags -1 fixed-upstream pending Hi Jim, upstream fixed the problem and I have backported the fix for Debian, so that it will be included in the next upload. Until then just disable ScanOnAccess to work around the problem. Best regards, Andreas After reading the discussion on the upstream bug report, it looks like perhaps these error messages in the logs were relevant after all... - ERROR: ScanOnAccess: fanotify_init failed: Operation not permitted - ScanOnAccess: clamd must be started by root Is ScanOnAccess something that is toggled depending on how you answer dpkg configuration questions? Or is it something I manually need to change in the /etc/clamav/clamd.conf ? I didn't see a question relevant to it at installation time. I have done a fresh install of clamav-daemon on a virtual machine and ScanOnAccess is set to false. To my knowledge I never manually set it to true on the system that I have the issue with. So I can only guess that it was enabled in one of the older clamav-daemon packages and subsequent upgrades have preserved the setting? I've been using this Debian system for many years (I think since around 2009) Either that, or I set it so long ago I just can't remember doing it. Thanks for all your help resolving the issue Andreas. I look forward to the fixed packages appearing in the Debian mirror. Regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
Hi Andreas. On 29/05/2014 5:10 PM, Andreas Cadhalpun wrote: Thanks for your help in finding the cause. Since the logs are inconclusive, it would really help if you could get us a backtrace, when clamd is hanging. For this install clamav-dbg and gdb. When it hangs again, please determine the PIDs of all clamd threads, e.g. with: ps -eL | grep clamd The second column contains this number. For every thread of clamd, run (replacing PID with the actual number): sudo gdb /usr/sbin/clamd PID And then in gdb: bt full The output of this should help to figure out, where exactly clamd is hanging. Okay, I have a hang, and I have the gdb output that you want. First the PID and Threads: # ps -eL | grep -P 'LWP|clamd' PID LWP TTY TIME CMD 26124 26124 ?00:00:11 clamd 26124 26126 ?00:00:00 clamd Then connecting to the first thread via gdb: # gdb /usr/sbin/clamd 26124 GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1+b1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/sbin/clamd...Reading symbols from /usr/lib/debug/usr/sbin/clamd...done. done. Attaching to program: /usr/sbin/clamd, process 26124 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or set sysroot? Reading symbols from /usr/lib/libclamav.so.6...Reading symbols from /usr/lib/debug/usr/lib/libclamav.so.6.1.23...done. done. Loaded symbols for /usr/lib/libclamav.so.6 Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.18.so...done. done. [New LWP 26126] [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.18.so...done. done. Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6 Reading symbols from /usr/lib/x86_64-linux-gnu/libxml2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libxml2.so.2 Reading symbols from /lib/x86_64-linux-gnu/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libz.so.1 Reading symbols from /lib/x86_64-linux-gnu/libbz2.so.1.0...(no debugging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libbz2.so.1.0 Reading symbols from /usr/lib/x86_64-linux-gnu/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libltdl.so.7 Reading symbols from /usr/lib/x86_64-linux-gnu/libffi.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libffi.so.6 Reading symbols from /usr/lib/x86_64-linux-gnu/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libstdc++.so.6 Reading symbols from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 Reading symbols from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.18.so...done. done. Loaded symbols for /lib/x86_64-linux-gnu/libm.so.6 Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libdl-2.18.so...done. done. Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2 Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libgcc_s.so.1 Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.18.so...done. done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/x86_64-linux-gnu/liblzma.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/liblzma.so.5 Reading symbols from /lib/x86_64-linux-gnu/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libnss_compat-2.18.so...done. done. Loaded symbols for /lib/x86_64-linux-gnu/libnss_compat.so.2 Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libnsl-2.18.so...done. done. Loaded symbols for /lib/x86_64-linux-gnu/libnsl.so.1 Reading symbols from /lib/x86_64-linux-gnu/libnss_nis.so.2...Reading symbols from
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
Control: forwarded -1 https://bugzilla.clamav.net/show_bug.cgi?id=11028 Hi Jim, On 04.06.2014 10:40, Jim Barber wrote: Okay, I have a hang, and I have the gdb output that you want. Thanks for the backtrace. First the PID and Threads: # ps -eL | grep -P 'LWP|clamd' PID LWP TTY TIME CMD 26124 26124 ?00:00:11 clamd 26124 26126 ?00:00:00 clamd Two threads, that's normal. Then connecting to the first thread via gdb: # gdb /usr/sbin/clamd 26124 [...] (gdb) bt full #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 So indeed this looks like a deadlock. But that's strange, as the other thread seems to be idle... No locals. #1 0x7ff480483467 in _L_lock_913 () from /lib/x86_64-linux-gnu/libpthread.so.0 No symbol table info available. #2 0x7ff480483290 in __GI___pthread_mutex_lock (mutex=0x6256a0 logg_mutex) at ../nptl/pthread_mutex_lock.c:79 __PRETTY_FUNCTION__ = __pthread_mutex_lock type = 4294966784 #3 0x00405f5f in logg (str=str@entry=0x41f8c9 Reading databases from %s\n) at ../shared/output.c:350 ../shared/output.c:350 is: pthread_mutex_lock(logg_mutex); That's surprising: I had thought the deadlock would happen with the reload_mutex, but it actually happens with the logg_mutex. It tries to log Reading databases from /var/lib/clamav and for this wants to lock the logg_mutex, but the mutex is apparently already locked, so clamd hangs. I can't see how this could happen, as the logg_mutex is always unlocked, before logg() returns, and the other thread is not in the process of logging something. Then I attach gdb to the other thread: # gdb /usr/sbin/clamd 26126 [...] (gdb) bt full #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 This thread is just waiting. #1 0x0040c421 in acceptloop_th (arg=0x75a3e540) at server-th.c:378 #2 0x7ff480481062 in start_thread (arg=0x7ff4651b9700) at pthread_create.c:312 #3 0x7ff4801b4c1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 [...] If there is anything else you need me to do (such as install other debug packages from some of the dependent libraries), let me know. I have forwarded this to upstream now. Let's see, what they say. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
Hi Andreas. On 29/05/2014 5:10 PM, Andreas Cadhalpun wrote: On 28.05.2014 02:55, Jim Barber wrote: On 2014-05-27 18:39, Andreas Cadhalpun wrote: I think the problem here is that there is a second 'Restarting on-access scan' message only 4 seconds after another one and without the usual 'ERROR: ScanOnAccess: fanotify_init [...]' between them. This looks as if the reload is started again, while the previous reload is not yet finished. Probably this should not happen, as it seems to cause a deadlock. It does appear that way. Higher up in the log there are also instances where two restarts happened within seconds of each other, but I guess were far enough apart to avoid the race/deadlock situation that the daemon seems to be encountering. Yes, it's strange. I tried to reproduce this, but failed. What I did: * Set ScanOnAccess to true. * Set SelfCheck to 10 seconds. * Stop the freshclam daemon: sudo service clamav-freshclam stop * Delete /var/lib/clamav/bytecode.cvd. * Run 'freshclam --daemon-notify=/etc/clamav/clamd.conf'. Repeating the last two steps, I saw three different patterns in the log. * Only one reload, triggered by freshclam. * Two reloads, but far enough apart, so that the 'ERROR:' message appears between them. * Two reloads, but without the 'ERROR:' message between them. Since it didn't hang in any of my tries, there must either be a really precise timing to cause the hang and I was lucky not to have it or there is something else needed. Since I enabled 'Debug true' in clamd.conf I haven't had a crash. Doing that must have modified the timing just enough to avoid the race/deadlock situation by the looks of things. It's been quite a number of days since I did this change now... I have upgraded to 0.98.4-rc1 again, but at this stage I've left the freshclam notications on to see if we can find the cause of the hangs. Thanks for your help in finding the cause. Since the logs are inconclusive, it would really help if you could get us a backtrace, when clamd is hanging. For this install clamav-dbg and gdb. When it hangs again, please determine the PIDs of all clamd threads, e.g. with: ps -eL | grep clamd The second column contains this number. For every thread of clamd, run (replacing PID with the actual number): sudo gdb /usr/sbin/clamd PID And then in gdb: bt full The output of this should help to figure out, where exactly clamd is hanging. Okay. When I get a chance I'll install the -dbg packages and I'll set 'Debug false' again since it seems to be preventing the hang, and I'll see if it hangs with the dbg packages in place and get the gdb info. If the -dbg packages also prevent the hang because of different timings then I guess we're out of luck to find the real cause of the hangs... Regards, Jim. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
Hi Jim, On 28.05.2014 02:55, Jim Barber wrote: On 2014-05-27 18:39, Andreas Cadhalpun wrote: I think the problem here is that there is a second 'Restarting on-access scan' message only 4 seconds after another one and without the usual 'ERROR: ScanOnAccess: fanotify_init [...]' between them. This looks as if the reload is started again, while the previous reload is not yet finished. Probably this should not happen, as it seems to cause a deadlock. It does appear that way. Higher up in the log there are also instances where two restarts happened within seconds of each other, but I guess were far enough apart to avoid the race/deadlock situation that the daemon seems to be encountering. Yes, it's strange. I tried to reproduce this, but failed. What I did: * Set ScanOnAccess to true. * Set SelfCheck to 10 seconds. * Stop the freshclam daemon: sudo service clamav-freshclam stop * Delete /var/lib/clamav/bytecode.cvd. * Run 'freshclam --daemon-notify=/etc/clamav/clamd.conf'. Repeating the last two steps, I saw three different patterns in the log. * Only one reload, triggered by freshclam. * Two reloads, but far enough apart, so that the 'ERROR:' message appears between them. * Two reloads, but without the 'ERROR:' message between them. Since it didn't hang in any of my tries, there must either be a really precise timing to cause the hang and I was lucky not to have it or there is something else needed. I have upgraded to 0.98.4-rc1 again, but at this stage I've left the freshclam notications on to see if we can find the cause of the hangs. Thanks for your help in finding the cause. Since the logs are inconclusive, it would really help if you could get us a backtrace, when clamd is hanging. For this install clamav-dbg and gdb. When it hangs again, please determine the PIDs of all clamd threads, e.g. with: ps -eL | grep clamd The second column contains this number. For every thread of clamd, run (replacing PID with the actual number): sudo gdb /usr/sbin/clamd PID And then in gdb: bt full The output of this should help to figure out, where exactly clamd is hanging. It looks like freshclam believes the notification was successful. Yes, that's what I expected. You can set 'Debug true' in clamd.conf. I have done this to see if there is more information the next time version 0.98.4-rc1 hangs. There is also a 'LogVerbose false' parameter. Is it worth settng that to true? Or is that pointless when you have Debug enabled? Yes, it's pointless, as Debug is the most verbose setting, overriding any LogVerbose setting. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
Hi Jim, On 27.05.2014 07:18, Jim Barber wrote: The ClamAV daemon hung again after rolling back to 0.98.3. You could try it with 0.98.1, but I'm not sure if that would help. It went longer than a day this time, but still less than 2 days. Here's the havp log (with URL removed). 25/05/2014 08:51:59 === Starting HAVP Version: 0.92 25/05/2014 08:51:59 Running as user: havp, group: havp 25/05/2014 08:51:59 Use parent proxy: localhost:3130 25/05/2014 08:51:59 --- Initializing Clamd Socket Scanner 25/05/2014 08:51:59 Clamd Socket Scanner passed EICAR virus test (Eicar-Test-Signature) 25/05/2014 08:51:59 --- All scanners initialized 25/05/2014 08:51:59 Process ID: 23108 26/05/2014 23:20:04 Error: Some scanner has timed out! (lasturl: url removed) The complete ClamAV log from when I started it after backing out to the older version, to when I restarted it when I noticed it was hung is as follows: Sun May 25 08:51:01 2014 - +++ Started at Sun May 25 08:51:01 2014 [...] Mon May 26 15:59:42 2014 - SelfCheck: Database status OK. Mon May 26 16:52:08 2014 - Restarting on-access scan Mon May 26 16:52:09 2014 - Reading databases from /var/lib/clamav Mon May 26 16:52:13 2014 - Database correctly reloaded (3387113 signatures) Mon May 26 16:52:13 2014 - ERROR: ScanOnAccess: fanotify_init failed: Operation not permitted Mon May 26 16:52:13 2014 - ScanOnAccess: clamd must be started by root Mon May 26 17:52:13 2014 - SelfCheck: Database status OK. Mon May 26 18:52:13 2014 - SelfCheck: Database status OK. Mon May 26 19:52:13 2014 - SelfCheck: Database status OK. Mon May 26 21:52:05 2014 - SelfCheck: Database status OK. Mon May 26 22:52:19 2014 - SelfCheck: Database modification detected. Forcing reload. Mon May 26 22:52:19 2014 - Restarting on-access scan Mon May 26 22:52:19 2014 - Reading databases from /var/lib/clamav Mon May 26 22:52:23 2014 - Database correctly reloaded (3387525 signatures) Mon May 26 22:52:23 2014 - Restarting on-access scan Tue May 27 06:39:04 2014 - +++ Started at Tue May 27 06:39:04 2014 It looks like it hung on 'Restarting on-access scan'. It didn't follow up with the following messages that usually happen seconds after: - Reading databases from /var/lib/clamav - Database correctly reloaded ([0-9]+ signatures) I think the problem here is that there is a second 'Restarting on-access scan' message only 4 seconds after another one and without the usual 'ERROR: ScanOnAccess: fanotify_init [...]' between them. This looks as if the reload is started again, while the previous reload is not yet finished. Probably this should not happen, as it seems to cause a deadlock. I used to run this version of the ClamAV daemon without issue. So maybe it is something to do with getting freshclam updates working again. I went back through my freshclam logs and it was fine up until the evening of Thu Apr 24th where I started getting the freshclam update error. Prior to that I wasn't getting hangs either though. Actually, when I ran 'dpkg-reconfigure clamav-freshclam' to fix the freshclam update errors, one of the questions asked was: Should clamd be notified after updates? I think this may have been 'No' before as I thought that was strange I would leave it set that way and I selected 'Yes'. So it is likely to be this that is now causing my hangs I guess. This may be, as the hang happens precisely when clamd itself notices a 'Database modification' and triggers a reload, likely just before freshclam triggers a reload. Nonetheless I think this is a bug in clamd, as it should handle this gracefully. Looking back over my past logs, the 'Restarting on-access scan' message used to happen infrequently: Fri Apr 25 00:01:13 2014 - Restarting on-access scan Tue Apr 29 13:41:24 2014 - Restarting on-access scan Mon May 5 00:07:08 2014 - Restarting on-access scan Thu May 8 19:46:58 2014 - Restarting on-access scan Sun May 11 18:47:52 2014 - Restarting on-access scan Fri May 16 17:48:07 2014 - Restarting on-access scan Mon May 19 23:15:10 2014 - Restarting on-access scan Then after the reconfigure of clamav-freshclam it is regular: Tue May 20 23:49:57 2014 - Restarting on-access scan Wed May 21 00:50:01 2014 - Restarting on-access scan Wed May 21 01:50:07 2014 - Restarting on-access scan Wed May 21 01:50:12 2014 - Restarting on-access scan Wed May 21 22:44:12 2014 - Restarting on-access scan Wed May 21 23:44:06 2014 - Restarting on-access scan Thu May 22 04:44:15 2014 - Restarting on-access scan Thu May 22 04:44:19 2014 - Restarting on-access scan Thu May 22 06:44:23 2014 - Restarting on-access scan Thu May 22 06:44:28 2014 - Restarting on-access scan Thu May 22 18:03:34 2014 - Restarting on-access scan Thu May 22 18:03:38 2014 - Restarting on-access scan Thu
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
Hi Andreas On 2014-05-27 18:39, Andreas Cadhalpun wrote: Hi Jim, You could try it with 0.98.1, but I'm not sure if that would help. I think I'll keep moving on with the new versions, and hopefully we can find the real problem. I think the problem here is that there is a second 'Restarting on-access scan' message only 4 seconds after another one and without the usual 'ERROR: ScanOnAccess: fanotify_init [...]' between them. This looks as if the reload is started again, while the previous reload is not yet finished. Probably this should not happen, as it seems to cause a deadlock. It does appear that way. Higher up in the log there are also instances where two restarts happened within seconds of each other, but I guess were far enough apart to avoid the race/deadlock situation that the daemon seems to be encountering. Shall I upgrade to 0.98.4~rc1 again and reconfigure freshclam to no longer notify the ClamAV daemon when an update is available? Yes, please try this and let us know, if it helps. I have upgraded to 0.98.4-rc1 again, but at this stage I've left the freshclam notications on to see if we can find the cause of the hangs. Also could you please check, if /var/log/clamav/freshclam.log contains 'Clamd successfully notified about the update.' around the time 'Mon May 26 22:52:23 2014', where the hang happened, or if there is a related error message. The freshclam logs around this time are as follows: Mon May 26 21:52:15 2014 - -- Mon May 26 22:52:15 2014 - Received signal: wake up Mon May 26 22:52:15 2014 - ClamAV update process started at Mon May 26 22:52:15 2014 Mon May 26 22:52:15 2014 - main.cld is up to date (version: 55, sigs: 2424225, f-level: 60, builder: neo) Mon May 26 22:52:16 2014 - Downloading daily-19034.cdiff [100%] Mon May 26 22:52:17 2014 - daily.cld updated (version: 19034, sigs: 968759, f-level: 63, builder: neo) Mon May 26 22:52:19 2014 - Database updated (3392984 signatures) from db.local.clamav.net (IP: 117.104.160.194) Mon May 26 22:52:23 2014 - Clamd successfully notified about the update. Mon May 26 22:52:23 2014 - -- Mon May 26 23:52:23 2014 - Received signal: wake up Mon May 26 23:52:23 2014 - ClamAV update process started at Mon May 26 23:52:23 2014 Mon May 26 23:52:23 2014 - main.cld is up to date (version: 55, sigs: 2424225, f-level: 60, builder: neo) Mon May 26 23:52:23 2014 - daily.cld is up to date (version: 19034, sigs: 968759, f-level: 63, builder: neo) Mon May 26 23:52:24 2014 - -- It looks like freshclam believes the notification was successful. You can set 'Debug true' in clamd.conf. I have done this to see if there is more information the next time version 0.98.4-rc1 hangs. There is also a 'LogVerbose false' parameter. Is it worth settng that to true? Or is that pointless when you have Debug enabled? Is the problem perhaps related to these messages? - ERROR: ScanOnAccess: fanotify_init failed: Operation not permitted - ScanOnAccess: clamd must be started by root I don't think this is related, but if the above doesn't help, you could try disabling ScanOnAccess or running clamd as root. Okay, I'll hold off on doing that for now since I also think this is probably not related. Jim. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
The ClamAV daemon hung again after rolling back to 0.98.3. It went longer than a day this time, but still less than 2 days. Here's the havp log (with URL removed). 25/05/2014 08:51:59 === Starting HAVP Version: 0.92 25/05/2014 08:51:59 Running as user: havp, group: havp 25/05/2014 08:51:59 Use parent proxy: localhost:3130 25/05/2014 08:51:59 --- Initializing Clamd Socket Scanner 25/05/2014 08:51:59 Clamd Socket Scanner passed EICAR virus test (Eicar-Test-Signature) 25/05/2014 08:51:59 --- All scanners initialized 25/05/2014 08:51:59 Process ID: 23108 26/05/2014 23:20:04 Error: Some scanner has timed out! (lasturl: url removed) The complete ClamAV log from when I started it after backing out to the older version, to when I restarted it when I noticed it was hung is as follows: Sun May 25 08:51:01 2014 - +++ Started at Sun May 25 08:51:01 2014 Sun May 25 08:51:01 2014 - clamd daemon 0.98.3 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64) Sun May 25 08:51:01 2014 - Log file size limited to 4294967295 bytes. Sun May 25 08:51:01 2014 - Reading databases from /var/lib/clamav Sun May 25 08:51:01 2014 - Not loading PUA signatures. Sun May 25 08:51:01 2014 - Bytecode: Security mode set to TrustSigned. Sun May 25 08:51:05 2014 - Loaded 3384653 signatures. Sun May 25 08:51:05 2014 - LOCAL: Unix socket file /var/run/clamav/clamd.ctl Sun May 25 08:51:05 2014 - LOCAL: Setting connection queue length to 15 Sun May 25 08:51:05 2014 - Limits: Global size limit set to 104857600 bytes. Sun May 25 08:51:05 2014 - Limits: File size limit set to 26214400 bytes. Sun May 25 08:51:05 2014 - Limits: Recursion level limit set to 10. Sun May 25 08:51:05 2014 - Limits: Files limit set to 1. Sun May 25 08:51:05 2014 - Limits: MaxEmbeddedPE limit set to 10485760 bytes. Sun May 25 08:51:05 2014 - Limits: MaxHTMLNormalize limit set to 10485760 bytes. Sun May 25 08:51:05 2014 - Limits: MaxHTMLNoTags limit set to 2097152 bytes. Sun May 25 08:51:05 2014 - Limits: MaxScriptNormalize limit set to 5242880 bytes. Sun May 25 08:51:05 2014 - Limits: MaxZipTypeRcg limit set to 1048576 bytes. Sun May 25 08:51:05 2014 - Limits: MaxPartitions limit set to 50. Sun May 25 08:51:05 2014 - Limits: MaxIconsPE limit set to 100. Sun May 25 08:51:05 2014 - Archive support enabled. Sun May 25 08:51:05 2014 - Algorithmic detection enabled. Sun May 25 08:51:05 2014 - Portable Executable support enabled. Sun May 25 08:51:05 2014 - ELF support enabled. Sun May 25 08:51:05 2014 - Mail files support enabled. Sun May 25 08:51:05 2014 - OLE2 support enabled. Sun May 25 08:51:05 2014 - PDF support enabled. Sun May 25 08:51:05 2014 - SWF support enabled. Sun May 25 08:51:05 2014 - HTML support enabled. Sun May 25 08:51:05 2014 - Self checking every 3600 seconds. Sun May 25 08:51:05 2014 - ERROR: ScanOnAccess: fanotify_init failed: Operation not permitted Sun May 25 08:51:05 2014 - ScanOnAccess: clamd must be started by root Sun May 25 08:51:59 2014 - /var/spool/havp/havp-UoR2B0: Eicar-Test-Signature(003059cf287f5a591fce287f:68) FOUND Sun May 25 09:51:06 2014 - No stats for Database check - forcing reload Sun May 25 09:51:06 2014 - Restarting on-access scan Sun May 25 09:51:07 2014 - Reading databases from /var/lib/clamav Sun May 25 09:51:11 2014 - Database correctly reloaded (3384653 signatures) Sun May 25 09:51:11 2014 - ERROR: ScanOnAccess: fanotify_init failed: Operation not permitted Sun May 25 09:51:11 2014 - ScanOnAccess: clamd must be started by root Sun May 25 10:51:10 2014 - Restarting on-access scan Sun May 25 10:51:11 2014 - Reading databases from /var/lib/clamav Sun May 25 10:51:15 2014 - Database correctly reloaded (3385141 signatures) Sun May 25 10:51:15 2014 - ERROR: ScanOnAccess: fanotify_init failed: Operation not permitted Sun May 25 10:51:15 2014 - ScanOnAccess: clamd must be started by root Sun May 25 12:45:23 2014 - SelfCheck: Database status OK. Sun May 25 14:12:17 2014 - SelfCheck: Database status OK. Sun May 25 15:12:17 2014 - SelfCheck: Database status OK. Sun May 25 16:12:17 2014 - SelfCheck: Database status OK. Sun May 25 17:16:51 2014 - SelfCheck: Database status OK. Sun May 25 18:27:02 2014 - SelfCheck: Database status OK. Sun May 25 20:15:13 2014 - SelfCheck: Database status OK. Sun May 25 21:24:16 2014 - SelfCheck: Database status OK. Sun May 25 22:45:52 2014 - SelfCheck: Database status OK. Sun May 25 22:51:29 2014 - Restarting on-access scan Sun May 25 22:51:29 2014 - Reading databases from /var/lib/clamav Sun May 25 22:51:33 2014 - Database correctly reloaded (3385585 signatures) Sun May 25 22:51:33 2014 - ERROR: ScanOnAccess: fanotify_init failed: Operation not permitted Sun May 25 22:51:33 2014 - ScanOnAccess: clamd must be started by root Mon
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
On 2014-05-23 20:13:54 [+0800], Jim Barber wrote: So the sequence of events was the upgrade on the 19th; freshclam on the 20th; then the first hang on the 21st. I see. Could you please go back to 0.98.3 and see if the issue goes away? It might be a regression in the comming up 0.98.4 of clamav. Just want to make sure. Regards, Jim Barber Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749027: [Pkg-clamav-devel] Bug#749027: The ClamAV daemon stops working.
On 2014-05-24 22:23, Sebastian Andrzej Siewior wrote: I see. Could you please go back to 0.98.3 and see if the issue goes away? It might be a regression in the comming up 0.98.4 of clamav. Just want to make sure. Sebastian Yes, I now have the following clamav packages installed on the system: # dpkg --list | grep clam | cut -c1-60 ii clamav 0.98.3+dfsg-1 amd64 ii clamav-base 0.98.3+dfsg-1 all ii clamav-daemon 0.98.3+dfsg-1 amd64 ii clamav-freshclam0.98.3+dfsg-1 amd64 ii libclamav6 0.98.3+dfsg-1 amd64 ii libclamunrar6 0.98.1-1 amd64 I'll provide an update in a few days if there have been no hangs. Or earlier if a hang occurs. Jim. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
