Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
I just wanted to add that I am also getting these errors on 2x Debian/testing hosts. I am not using squidclamav but instead I'm using the libc-icap-mod-virus-scan package. Details of the installed packages that I think may be relevant are: $ dpkg --list | grep -P 'clam|icap|squid' ii c-icap1:0.3.4-2 amd64 ICAP server implementation ii clamav0.98.6+dfsg-1 amd64 anti-virus utility for Unix - command-line interface ii clamav-base 0.98.6+dfsg-1 all anti-virus utility for Unix - base package ii clamav-freshclam 0.98.6+dfsg-1 amd64 anti-virus utility for Unix - virus database update utility ii libc-icap-mod-virus-scan 1:0.3.2-2 amd64 Antivirus Service for c-icap ii libclamav60.98.6+dfsg-1 amd64 anti-virus utility for Unix - library ii libicapapi3 1:0.3.4-2 amd64 ICAP API library ii squid-langpack20140506-1all Localized error pages for Squid ii squid33.4.8-6 amd64 Full featured Web Proxy cache (HTTP proxy) ii squid3-common 3.4.8-6 all Full featured Web Proxy cache (HTTP proxy) - common files I currently have ICAP daemon disabled: $ grep START /etc/default/c-icap START=no $ ps -ef | grep icap jimb 1936 793 0 11:10 pts/100:00:00 grep icap I have not defined icap_enabled (my 'icap_enabled on' directive is currently commented out), and so it should default to 'off' However I still have configuration in place for icap in squid, and this seems to be enough to trigger the error. The icap config changes made in /etc/squid/squid3.conf are: # Disable for now... #icap_enable on icap_preview_size 1024 adaptation_send_client_ip on icap_client_username_header X-Authenticated-User icap_service service_avi_req reqmod_precache icap://localhost:1344/avscan bypass=on icap_service service_avi_resp respmod_precache icap://localhost:1344/avscan bypass=on adaptation_access service_avi_req allow all adaptation_access service_avi_resp allow all Regards, Jim Barber -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
Can someone able to replicate this issue please test the upstream patch: http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3-13407.patch Amos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
On Fri, 12 Sep 2014 08:01:25 -0500 Dale Schroeder wrote: I don't understand how a log rotation can fail, yet succeed. The way the log rotation integrates with external log management tools is that Squid leaves the external tool to do file renaming or moving, and just re-opens the filedescriptors it has for the log files. So the logs have been changed successfully by logrotated. But the squid binary is asserting at some point in the followup process. The assertion seems to be caused by memory management for some globals allocated for the ICAP services. Hello, I have noticed the same error during log rotation. I have icap_enable off (default) and no squidclamav (almost default config) but I have ecap_service gzip_service respmod_precache ... loadable_modules /usr/lib/squid3/ecap_adapter_gzip.so adaptation_access gzip_service allow GZIP_HTTP_STATUS ^ correlates with bug#4057 mentioned above Now when I run squid from command line (with another instance running in background), it segfauls: # gdb /usr/sbin/squid3 Reading symbols from /usr/sbin/squid3...Reading symbols from /usr/lib/debug//usr/sbin/squid3...done. (gdb) run Starting program: /usr/sbin/squid3 [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. Program received signal SIGABRT, Aborted. 0xb7fde424 in __kernel_vsyscall () (gdb) bt #0 0xb7fde424 in __kernel_vsyscall () #1 0xb78f9307 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb78fa9c3 in __GI_abort () at abort.c:89 #3 0x801470a4 in xassert (msg=0x80438250 size == StrPoolsAttrs[i].obj_size, file=0x8043f7c4 mem.cc, line=282) at debug.cc:566 #4 0x801f0fc7 in memFreeString (size=721, buf=0x806c87e0) at mem.cc:282 #5 0x80233e1a in String::clean (this=0x806ccd0c) at String.cc:159 #6 0x80399033 in Adaptation::AccessRule::~AccessRule (this=0x806ccd08, __in_chrg=optimized out) at AccessRule.cc:16 #7 0x80399f4a in Adaptation::Config::FreeAccess () at Config.cc:281 #8 0x8039ad64 in Adaptation::Config::freeService (this=0x806b34c0 Adaptation::Icap::TheConfig) at Config.cc:148 #9 0x8039adb8 in Adaptation::Config::~Config (this=0x806b34c0 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:307 #10 0x803b5d04 in Adaptation::Icap::Config::~Config (this=0x806b34c0 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:54 #11 0xb78fc121 in __run_exit_handlers (status=status@entry=0, listp=0xb7a723c4 __exit_funcs, run_list_atexit=run_list_atexit@entry=true) at exit.c:82 #12 0xb78fc17d in __GI_exit (status=0) at exit.c:104 #13 0x801ee9cf in watch_child (argv=optimized out) at main.cc:1687 #14 SquidMain (argc=1, argv=0xba94) at main.cc:1452 #15 0x800d5c79 in SquidMainSafe (argv=0xba94, argc=1) at main.cc:1260 #16 main (argc=1, argv=0xba94) at main.cc:1252 In /var/log/squid3/cache.log: 2014/11/11 01:30:36| Squid is already running! Process ID 22357 2014/11/11 01:30:36| assertion failed: mem.cc:282: size == StrPoolsAttrs[i].obj_size I am running squid 3.4.8-2 / jessie -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
forwarded 760303 http://bugs.squid-cache.org/show_bug.cgi?id=4057 On Fri, 12 Sep 2014 08:01:25 -0500 Dale Schroeder wrote: I don't understand how a log rotation can fail, yet succeed. The way the log rotation integrates with external log management tools is that Squid leaves the external tool to do file renaming or moving, and just re-opens the filedescriptors it has for the log files. So the logs have been changed successfully by logrotated. But the squid binary is asserting at some point in the followup process. The assertion seems to be caused by memory management for some globals allocated for the ICAP services. Amos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
signature Dale Schroeder Technical Issues Del Sol Food Company, Inc. (979)836-5978(979) 836-5978 On 09/11/2014 2:34 PM, Gilles Darold wrote: Le 10/09/2014 20:49, Dale Schroeder a écrit : On 09/10/2014 11:41 AM, Mathieu Parent (Debian) wrote: 2014-09-10 17:02 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: [...] With the squidclamav service commented out in c-icap.conf and squidclamav package uninstalled, this is the backtrace output: [...] squidclamav directives were active in squid.conf. As mentioned in a previous email, commenting the squidclamav directives in squid.conf allows squid3 to start/restart without error. This looks like a squid problem then. Quite possibly, or a squidclamav conflict. Gilles from squidclamav offered to test with the Debian versions of squid3 and c-icap, but has not yet reported back. I have not heard from squid3 maintainer Luigi Gangitano. I'll add him to the thread. I have had no luck with tcpdump using the following command: tcpdump -w /root/capture.log host 127.0.0.1 and port 1344 Try: tcpdump -i lo -w /root/capture.log host 127.0.0.1 and port 1344 No change; capture.log is still empty. Note that I won't probably solve your problem as it seems too deep in the code for me. I appreciate your help. Regards I have play a little this night with a squid3+c-icap+squidanalyzer in the same version as you. The most difficult for me was to understand how to install testing packages. Distributor ID:Debian Description:Debian GNU/Linux 7.6 (wheezy) Release:7.6 Codename:wheezy ii c-icap 1:0.3.4-1 amd64 ICAP server implementation ii squid3 3.3.8-1.2 amd64 Full featured Web Proxy cache (HTTP proxy) and squidclamav-6.11 compiled Everything works great for me I was able to view my favorit concert of the moment:-) But after restarting squid3 I also have the following entries in my syslog file Sep 11 21:22:16 gilles-debian kernel: [ 9360.558097] squid3[4919]: segfault at 0 ip 7f8a88d8e010 sp 7fff6eaddb50 error 4 in squid3[7f8a88a28000+49b000] Sep 11 21:22:17 gilles-debian squid3[4987]: Squid Parent: will start 1 kids Sep 11 21:22:17 gilles-debian squid3[4987]: Squid Parent: (squid-1) process 4992 started Outside those entries in /var/log/syslog everything work like a charm, I keep watching video through c-icap+squidclamav without any problem. Here what I have in cache.log at the time of the segfault: [...] My experience is similar to yours. Even with the segfault, squid3 starts and functions. Additionally, the log rotation seems to fail. I get an email showing errors and an exit code, but when I check the logs, there is one for each day as defined in logratate. /etc/cron.daily/logrotate: 2014/09/12 06:25:21| assertion failed: mem.cc:281: size == StrPoolsAttrs[i].obj_size Aborted error: error running shared postrotate script for '/var/log/squid3/*.log ' run-parts: /etc/cron.daily/logrotate exited with return code 1 I don't understand how a log rotation can fail, yet succeed. Gilles, thank you for your efforts. Dale
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
Le 10/09/2014 20:49, Dale Schroeder a écrit : On 09/10/2014 11:41 AM, Mathieu Parent (Debian) wrote: 2014-09-10 17:02 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: [...] With the squidclamav service commented out in c-icap.conf and squidclamav package uninstalled, this is the backtrace output: [...] squidclamav directives were active in squid.conf. As mentioned in a previous email, commenting the squidclamav directives in squid.conf allows squid3 to start/restart without error. This looks like a squid problem then. Quite possibly, or a squidclamav conflict. Gilles from squidclamav offered to test with the Debian versions of squid3 and c-icap, but has not yet reported back. I have not heard from squid3 maintainer Luigi Gangitano. I'll add him to the thread. I have had no luck with tcpdump using the following command: tcpdump -w /root/capture.log host 127.0.0.1 and port 1344 Try: tcpdump -i lo -w /root/capture.log host 127.0.0.1 and port 1344 No change; capture.log is still empty. Note that I won't probably solve your problem as it seems too deep in the code for me. I appreciate your help. Regards I have play a little this night with a squid3+c-icap+squidanalyzer in the same version as you. The most difficult for me was to understand how to install testing packages. Distributor ID:Debian Description:Debian GNU/Linux 7.6 (wheezy) Release:7.6 Codename:wheezy ii c-icap 1:0.3.4-1 amd64 ICAP server implementation ii squid3 3.3.8-1.2 amd64 Full featured Web Proxy cache (HTTP proxy) and squidclamav-6.11 compiled Everything works great for me I was able to view my favorit concert of the moment:-) But after restarting squid3 I also have the following entries in my syslog file Sep 11 21:22:16 gilles-debian kernel: [ 9360.558097] squid3[4919]: segfault at 0 ip 7f8a88d8e010 sp 7fff6eaddb50 error 4 in squid3[7f8a88a28000+49b000] Sep 11 21:22:17 gilles-debian squid3[4987]: Squid Parent: will start 1 kids Sep 11 21:22:17 gilles-debian squid3[4987]: Squid Parent: (squid-1) process 4992 started Outside those entries in /var/log/syslog everything work like a charm, I keep watching video through c-icap+squidclamav without any problem. Here what I have in cache.log at the time of the segfault: 2014/09/11 21:22:16 kid1| Shutting down... 2014/09/11 21:22:16.262 kid1| comm.cc(1102) _comm_close: comm_close: start closing FD 8 2014/09/11 21:22:16.262 kid1| comm.cc(760) commUnsetFdTimeout: Remove timeout for FD 8 2014/09/11 21:22:16.262 kid1| comm.cc(955) commCallCloseHandlers: commCallCloseHandlers: FD 8 2014/09/11 21:22:16.262 kid1| AsyncCall.cc(18) AsyncCall: The AsyncCall comm_close_complete constructed, this=0x7f8a896b7a60 [call18761] 2014/09/11 21:22:16.262 kid1| AsyncCall.cc(85) ScheduleCall: comm.cc(1178) will call comm_close_complete(FD 8) [call18761] 2014/09/11 21:22:16.262 kid1| comm.cc(1102) _comm_close: comm_close: start closing FD 7 2014/09/11 21:22:16.262 kid1| comm.cc(760) commUnsetFdTimeout: Remove timeout for FD 7 2014/09/11 21:22:16.262 kid1| comm.cc(955) commCallCloseHandlers: commCallCloseHandlers: FD 7 2014/09/11 21:22:16.262 kid1| AsyncCall.cc(18) AsyncCall: The AsyncCall comm_close_complete constructed, this=0x7f8a896c06d0 [call18762] 2014/09/11 21:22:16.262 kid1| AsyncCall.cc(85) ScheduleCall: comm.cc(1178) will call comm_close_complete(FD 7) [call18762] 2014/09/11 21:22:16.262 kid1| comm.cc(1781) commCloseAllSockets: commCloseAllSockets: FD 7: calling comm_reset_close() 2014/09/11 21:22:16.262 kid1| comm.cc(1102) _comm_close: comm_close: start closing FD 7 2014/09/11 21:22:16.262 kid1| comm.cc(1781) commCloseAllSockets: commCloseAllSockets: FD 8: calling comm_reset_close() 2014/09/11 21:22:16.262 kid1| comm.cc(1102) _comm_close: comm_close: start closing FD 8 2014/09/11 21:22:16.262 kid1| comm.cc(1778) commCloseAllSockets: commCloseAllSockets: FD 14: Calling timeout handler 2014/09/11 21:22:16.262 kid1| AsyncCall.cc(85) ScheduleCall: comm.cc(1779) will call IdleConnList::Timeout(local=127.0.0.1:39602 remote=127.0.0.1:1344 FD 14 flags=1, data=0x7f8a896bb498) [call18650] 2014/09/11 21:22:16.263 kid1| comm.cc(1778) commCloseAllSockets: commCloseAllSockets: FD 17: Calling timeout handler 2014/09/11 21:22:16.263 kid1| AsyncCall.cc(85) ScheduleCall: comm.cc(1779) will call IdleConnList::Timeout(local=127.0.0.1:39604 remote=127.0.0.1:1344 FD 17 flags=1, data=0x7f8a896bc8f8) [call18623] 2014/09/11 21:22:16.263 kid1| comm.cc(1778) commCloseAllSockets: commCloseAllSockets: FD 19: Calling timeout handler 2014/09/11 21:22:16.263 kid1| AsyncCall.cc(85) ScheduleCall: comm.cc(1779) will call IdleConnList::Timeout(local=192.168.1.162:46841 remote=173.194.45.36:80 FD 19 flags=1, data=0x7f8a897237b8) [call9105] 2014/09/11 21:22:16.263 kid1| comm.cc(1778) commCloseAllSockets: commCloseAllSockets: FD 20: Calling timeout handler 2014/09/11 21:22:16.263 kid1|
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
2014-09-09 19:06 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: [...] Here's a picture of the screen when I type run squid3 under gdb [...] If I did my research correctly, here's the backtrace output: #0 0xb7fde424 in __kernel_vsyscall () #1 0xb792f267 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7930923 in __GI_abort () at abort.c:89 #3 0x801312f4 in xassert (msg=0x803d4c28 size == StrPoolsAttrs[i].obj_size, file=0x803dbf5c mem.cc, line=281) at debug.cc:565 #4 0x801cc057 in memFreeString (size=529, buf=0xb7aa8450 main_arena+48) at mem.cc:281 #5 0x8020892a in String::clean (this=0x80650fd4) at String.cc:159 #6 0x80341e4c in Adaptation::AccessRule::~AccessRule (this=0x80650fd0, __in_chrg=optimized out) at AccessRule.cc:15 #7 0x80342cc5 in Adaptation::Config::FreeAccess () at Config.cc:370 #8 0x803430a4 in Adaptation::Config::freeService (this=0x80645e00 Adaptation::Icap::TheConfig) at Config.cc:177 #9 0x803430f8 in Adaptation::Config::~Config (this=0x80645e00 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:396 #10 0x8035d914 in Adaptation::Icap::Config::~Config (this=0x80645e00 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:54 #11 0xb7932081 in __run_exit_handlers (status=status@entry=0, listp=0xb7aa83c4 __exit_funcs, run_list_atexit=run_list_atexit@entry=true) at exit.c:82 #12 0xb79320dd in __GI_exit (status=0) at exit.c:104 #13 0x801c951f in watch_child (argv=optimized out) at main.cc:1679 #14 SquidMain (argc=2, argv=0xb7d4) at main.cc:1441 #15 0x800cd089 in SquidMainSafe (argv=0xb7d4, argc=2) at main.cc:1242 #16 main (argc=2, argv=0xb7d4) at main.cc:1234 Great! This is what I wanted. But I couldn't find any releavant change in the 3.3 ( 3.3.8) changelog. Can you reproduce the crash while using c-icap without squidclamav? Can you provide a network capture (using tcpdump host 127.0.0.1 port 1344)? I'm using backported squid 3.3.8 with c-icap without a problem... -- Mathieu Parent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
On 09/10/2014 1:11 AM, Mathieu Parent (Debian) wrote: 2014-09-09 19:06 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: [...] Here's a picture of the screen when I type run squid3 under gdb [...] If I did my research correctly, here's the backtrace output: #0 0xb7fde424 in __kernel_vsyscall () #1 0xb792f267 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7930923 in __GI_abort () at abort.c:89 #3 0x801312f4 in xassert (msg=0x803d4c28 size == StrPoolsAttrs[i].obj_size, file=0x803dbf5c mem.cc, line=281) at debug.cc:565 #4 0x801cc057 in memFreeString (size=529, buf=0xb7aa8450 main_arena+48) at mem.cc:281 #5 0x8020892a in String::clean (this=0x80650fd4) at String.cc:159 #6 0x80341e4c in Adaptation::AccessRule::~AccessRule (this=0x80650fd0, __in_chrg=optimized out) at AccessRule.cc:15 #7 0x80342cc5 in Adaptation::Config::FreeAccess () at Config.cc:370 #8 0x803430a4 in Adaptation::Config::freeService (this=0x80645e00 Adaptation::Icap::TheConfig) at Config.cc:177 #9 0x803430f8 in Adaptation::Config::~Config (this=0x80645e00 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:396 #10 0x8035d914 in Adaptation::Icap::Config::~Config (this=0x80645e00 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:54 #11 0xb7932081 in __run_exit_handlers (status=status@entry=0, listp=0xb7aa83c4 __exit_funcs, run_list_atexit=run_list_atexit@entry=true) at exit.c:82 #12 0xb79320dd in __GI_exit (status=0) at exit.c:104 #13 0x801c951f in watch_child (argv=optimized out) at main.cc:1679 #14 SquidMain (argc=2, argv=0xb7d4) at main.cc:1441 #15 0x800cd089 in SquidMainSafe (argv=0xb7d4, argc=2) at main.cc:1242 #16 main (argc=2, argv=0xb7d4) at main.cc:1234 Great! This is what I wanted. But I couldn't find any releavant change in the 3.3 ( 3.3.8) changelog. Can you reproduce the crash while using c-icap without squidclamav? Can you provide a network capture (using tcpdump host 127.0.0.1 port 1344)? I'm using backported squid 3.3.8 with c-icap without a problem... With the squidclamav service commented out in c-icap.conf and squidclamav package uninstalled, this is the backtrace output: Starting program: /usr/sbin/squid3 [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. Program received signal SIGABRT, Aborted. 0xb7fde424 in __kernel_vsyscall () #0 0xb7fde424 in __kernel_vsyscall () #1 0xb792f267 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7930923 in __GI_abort () at abort.c:89 #3 0x801312f4 in xassert (msg=0x803d4c28 size == StrPoolsAttrs[i].obj_size, file=0x803dbf5c mem.cc, line=281) at debug.cc:565 #4 0x801cc057 in memFreeString (size=529, buf=0xb7aa8450 main_arena+48) at mem.cc:281 #5 0x8020892a in String::clean (this=0x80650fd4) at String.cc:159 #6 0x80341e4c in Adaptation::AccessRule::~AccessRule (this=0x80650fd0, __in_chrg=optimized out) at AccessRule.cc:15 #7 0x80342cc5 in Adaptation::Config::FreeAccess () at Config.cc:370 #8 0x803430a4 in Adaptation::Config::freeService (this=0x80645e00 Adaptation::Icap::TheConfig) at Config.cc:177 #9 0x803430f8 in Adaptation::Config::~Config (this=0x80645e00 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:396 #10 0x8035d914 in Adaptation::Icap::Config::~Config (this=0x80645e00 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:54 #11 0xb7932081 in __run_exit_handlers (status=status@entry=0, listp=0xb7aa83c4 __exit_funcs, run_list_atexit=run_list_atexit@entry=true) at exit.c:82 #12 0xb79320dd in __GI_exit (status=0) at exit.c:104 #13 0x801c951f in watch_child (argv=optimized out) at main.cc:1679 #14 SquidMain (argc=1, argv=0xb7d4) at main.cc:1441 #15 0x800cd089 in SquidMainSafe (argv=0xb7d4, argc=1) at main.cc:1242 #16 main (argc=1, argv=0xb7d4) at main.cc:1234 squidclamav directives were active in squid.conf. As mentioned in a previous email, commenting the squidclamav directives in squid.conf allows squid3 to start/restart without error. I have had no luck with tcpdump using the following command: tcpdump -w /root/capture.log host 127.0.0.1 and port 1344 I tried this both with and without squidclamav being activated. The log file is always empty. If the command needs to be altered, please let me know. Thanks for all the help. Dale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
2014-09-10 17:02 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: [...] With the squidclamav service commented out in c-icap.conf and squidclamav package uninstalled, this is the backtrace output: [...] squidclamav directives were active in squid.conf. As mentioned in a previous email, commenting the squidclamav directives in squid.conf allows squid3 to start/restart without error. This looks like a squid problem then. I have had no luck with tcpdump using the following command: tcpdump -w /root/capture.log host 127.0.0.1 and port 1344 Try: tcpdump -i lo -w /root/capture.log host 127.0.0.1 and port 1344 Note that I won't probably solve your problem as it seems too deep in the code for me. Regards -- Mathieu Parent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
On 09/10/2014 11:41 AM, Mathieu Parent (Debian) wrote: 2014-09-10 17:02 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: [...] With the squidclamav service commented out in c-icap.conf and squidclamav package uninstalled, this is the backtrace output: [...] squidclamav directives were active in squid.conf. As mentioned in a previous email, commenting the squidclamav directives in squid.conf allows squid3 to start/restart without error. This looks like a squid problem then. Quite possibly, or a squidclamav conflict. Gilles from squidclamav offered to test with the Debian versions of squid3 and c-icap, but has not yet reported back. I have not heard from squid3 maintainer Luigi Gangitano. I'll add him to the thread. I have had no luck with tcpdump using the following command: tcpdump -w /root/capture.log host 127.0.0.1 and port 1344 Try: tcpdump -i lo -w /root/capture.log host 127.0.0.1 and port 1344 No change; capture.log is still empty. Note that I won't probably solve your problem as it seems too deep in the code for me. I appreciate your help. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
On 09/08/2014 3:24 PM, Gilles Darold wrote: Le 08/09/2014 19:31, Dale Schroeder a écrit : It looks like I have found the culprit, and it seems to be specific to users of squidclamav, like me. If I comment the following lines in squid.conf, then squid3 starts and restarts with no errors. icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_resp allow all So, there now appears to be a conflict of some sort between squidclamav and squid3. I have tried with squidclamav versions 6.10 and 6.11, having identical results. I've copied the squidclamav developer on this message to see if the cause of the problem can be determined. Thanks. Dale Hi, I'm the maintainer of SquidClamav and I'm afraid that the culprit is not the one you are suspecting or at least it is not so obvious. I have a VM with squid3 3.3.8-1 and SquidClamav 6.11, I used it a few days ago to test icap service chaining with qlproxy. Everything works great, I'm able to watch a web TV stream scanned by clamd through SquidClamav. I have run logrotate and stop/start squid3 manually but I'm not able to reproduce your issue. There's some differences with your installation : * even if the base is a Debian jessie/sid this is an Ubuntu server distribution * I have not updated squid to 3.3.8-1.2 * I've run c-icap + squidclamav on an other server. Ok I know that's not really helpful. Let me install c-icap on the server with squidclamav. Done. Using c-icap 0.3.4 and SquidClamav 6.11 installed on the same server than squid doesn't change anything, I'm still able to watch the web TV. Of course when I stop squid3, the service is interrupted but after restarting squid I don't any segfault in the logs. So I hope you are agree that SquidClamav is not the culprit in your bug. What is your version of c-icap ? Note that if you are using c-icap 0.1.6, it will not works with SquidClamav. Let me known if/how I can help more. Regards, Gilles, Thank you for replying. Obviously, you are correct in that c-icap is also involved. Perhaps Jessie's versions of squid3 and c-icap do not cooperate with each other. I cannot say, as there are no other entries in the logs other than what I posted in my initial bug report. Since the config lines I disabled were about squidclamav, I made the deduction that it was the problem, and the assumption I made may not be correct. The evidence you have provided is quite compelling. c-icap is version 0.3.4-1 squid is version 3.3.8-1.2 squidclamav is version 6.11 As Debian no longer has squidclamav in its repositories, it may be difficult to find a solution, but I will add c-icap's maintainers to this thread to see if any are willing to look at this for potential conflicts. Thanks again. Dale Schroeder -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
Hello all, 2014-09-08 22:59 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: On 09/08/2014 3:24 PM, Gilles Darold wrote: Le 08/09/2014 19:31, Dale Schroeder a écrit : It looks like I have found the culprit, and it seems to be specific to users of squidclamav, like me. If I comment the following lines in squid.conf, then squid3 starts and restarts with no errors. icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_resp allow all So, there now appears to be a conflict of some sort between squidclamav and squid3. I have tried with squidclamav versions 6.10 and 6.11, having identical results. I've copied the squidclamav developer on this message to see if the cause of the problem can be determined. Thanks. Dale Hi, I'm the maintainer of SquidClamav and I'm afraid that the culprit is not the one you are suspecting or at least it is not so obvious. I have a VM with squid3 3.3.8-1 and SquidClamav 6.11, I used it a few days ago to test icap service chaining with qlproxy. Everything works great, I'm able to watch a web TV stream scanned by clamd through SquidClamav. I have run logrotate and stop/start squid3 manually but I'm not able to reproduce your issue. There's some differences with your installation : * even if the base is a Debian jessie/sid this is an Ubuntu server distribution * I have not updated squid to 3.3.8-1.2 * I've run c-icap + squidclamav on an other server. Ok I know that's not really helpful. Let me install c-icap on the server with squidclamav. Done. Using c-icap 0.3.4 and SquidClamav 6.11 installed on the same server than squid doesn't change anything, I'm still able to watch the web TV. Of course when I stop squid3, the service is interrupted but after restarting squid I don't any segfault in the logs. So I hope you are agree that SquidClamav is not the culprit in your bug. What is your version of c-icap ? Note that if you are using c-icap 0.1.6, it will not works with SquidClamav. Let me known if/how I can help more. Regards, Gilles, Thank you for replying. Obviously, you are correct in that c-icap is also involved. Perhaps Jessie's versions of squid3 and c-icap do not cooperate with each other. I cannot say, as there are no other entries in the logs other than what I posted in my initial bug report. Since the config lines I disabled were about squidclamav, I made the deduction that it was the problem, and the assumption I made may not be correct. The evidence you have provided is quite compelling. c-icap is version 0.3.4-1 squid is version 3.3.8-1.2 squidclamav is version 6.11 As Debian no longer has squidclamav in its repositories, it may be difficult to find a solution, but I will add c-icap's maintainers to this thread to see if any are willing to look at this for potential conflicts. Thanks again. Dale Schroeder I don't use squidclamav. Can you install squid3-dbg (and gdb) and run squid3 under gdb to see were the bug is. Squid3 in sid has not been updated since a while. I hope it will happen before jessie! Regards -- Mathieu Parent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
Le 08/09/2014 22:59, Dale Schroeder a écrit : On 09/08/2014 3:24 PM, Gilles Darold wrote: Le 08/09/2014 19:31, Dale Schroeder a écrit : It looks like I have found the culprit, and it seems to be specific to users of squidclamav, like me. If I comment the following lines in squid.conf, then squid3 starts and restarts with no errors. icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_resp allow all So, there now appears to be a conflict of some sort between squidclamav and squid3. I have tried with squidclamav versions 6.10 and 6.11, having identical results. I've copied the squidclamav developer on this message to see if the cause of the problem can be determined. Thanks. Dale Hi, I'm the maintainer of SquidClamav and I'm afraid that the culprit is not the one you are suspecting or at least it is not so obvious. I have a VM with squid3 3.3.8-1 and SquidClamav 6.11, I used it a few days ago to test icap service chaining with qlproxy. Everything works great, I'm able to watch a web TV stream scanned by clamd through SquidClamav. I have run logrotate and stop/start squid3 manually but I'm not able to reproduce your issue. There's some differences with your installation : * even if the base is a Debian jessie/sid this is an Ubuntu server distribution * I have not updated squid to 3.3.8-1.2 * I've run c-icap + squidclamav on an other server. Ok I know that's not really helpful. Let me install c-icap on the server with squidclamav. Done. Using c-icap 0.3.4 and SquidClamav 6.11 installed on the same server than squid doesn't change anything, I'm still able to watch the web TV. Of course when I stop squid3, the service is interrupted but after restarting squid I don't any segfault in the logs. So I hope you are agree that SquidClamav is not the culprit in your bug. What is your version of c-icap ? Note that if you are using c-icap 0.1.6, it will not works with SquidClamav. Let me known if/how I can help more. Regards, Gilles, Thank you for replying. Obviously, you are correct in that c-icap is also involved. Perhaps Jessie's versions of squid3 and c-icap do not cooperate with each other. I cannot say, as there are no other entries in the logs other than what I posted in my initial bug report. Since the config lines I disabled were about squidclamav, I made the deduction that it was the problem, and the assumption I made may not be correct. The evidence you have provided is quite compelling. c-icap is version 0.3.4-1 squid is version 3.3.8-1.2 squidclamav is version 6.11 As Debian no longer has squidclamav in its repositories, it may be difficult to find a solution, but I will add c-icap's maintainers to this thread to see if any are willing to look at this for potential conflicts. Thanks again. Dale Schroeder Hum, if you use c-icap 0.3.4 I don't any reason of that failure. The only difference with my installation is that I use a self compiled version of c-icap and squidclamav. Can you tell me how I can install the c-icap 0.3.4-1 and squid 3.3.8-1.2 package ? Is there's a particular repo for those package ? I suppose that squidclamav is self compiled on the server. I will install a Debian with this configuration and make tests, that's more easy for me to do that. The longer here for me is to download the Debian iso as I have very low bandwidth. Regards, -- Gilles GPL tools at http://www.darold.net/ (squidclamav - sendmailanalyzer - ora2pg - modproxyhtml - pgCluu squidguardmgr - sysusage - squidanalyzer - pgbadger - pgformatter) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
On 09/09/2014 8:50 AM, Gilles Darold wrote: Le 08/09/2014 22:59, Dale Schroeder a écrit : On 09/08/2014 3:24 PM, Gilles Darold wrote: Le 08/09/2014 19:31, Dale Schroeder a écrit : It looks like I have found the culprit, and it seems to be specific to users of squidclamav, like me. If I comment the following lines in squid.conf, then squid3 starts and restarts with no errors. icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_resp allow all So, there now appears to be a conflict of some sort between squidclamav and squid3. I have tried with squidclamav versions 6.10 and 6.11, having identical results. I've copied the squidclamav developer on this message to see if the cause of the problem can be determined. Thanks. Dale Hi, I'm the maintainer of SquidClamav and I'm afraid that the culprit is not the one you are suspecting or at least it is not so obvious. I have a VM with squid3 3.3.8-1 and SquidClamav 6.11, I used it a few days ago to test icap service chaining with qlproxy. Everything works great, I'm able to watch a web TV stream scanned by clamd through SquidClamav. I have run logrotate and stop/start squid3 manually but I'm not able to reproduce your issue. There's some differences with your installation : * even if the base is a Debian jessie/sid this is an Ubuntu server distribution * I have not updated squid to 3.3.8-1.2 * I've run c-icap + squidclamav on an other server. Ok I know that's not really helpful. Let me install c-icap on the server with squidclamav. Done. Using c-icap 0.3.4 and SquidClamav 6.11 installed on the same server than squid doesn't change anything, I'm still able to watch the web TV. Of course when I stop squid3, the service is interrupted but after restarting squid I don't any segfault in the logs. So I hope you are agree that SquidClamav is not the culprit in your bug. What is your version of c-icap ? Note that if you are using c-icap 0.1.6, it will not works with SquidClamav. Let me known if/how I can help more. Regards, Gilles, Thank you for replying. Obviously, you are correct in that c-icap is also involved. Perhaps Jessie's versions of squid3 and c-icap do not cooperate with each other. I cannot say, as there are no other entries in the logs other than what I posted in my initial bug report. Since the config lines I disabled were about squidclamav, I made the deduction that it was the problem, and the assumption I made may not be correct. The evidence you have provided is quite compelling. c-icap is version 0.3.4-1 squid is version 3.3.8-1.2 squidclamav is version 6.11 As Debian no longer has squidclamav in its repositories, it may be difficult to find a solution, but I will add c-icap's maintainers to this thread to see if any are willing to look at this for potential conflicts. Thanks again. Dale Schroeder Hum, if you use c-icap 0.3.4 I don't any reason of that failure. The only difference with my installation is that I use a self compiled version of c-icap and squidclamav. Can you tell me how I can install the c-icap 0.3.4-1 and squid 3.3.8-1.2 package ? Is there's a particular repo for those package ? I suppose that squidclamav is self compiled on the server. I will install a Debian with this configuration and make tests, that's more easy for me to do that. The longer here for me is to download the Debian iso as I have very low bandwidth. Regards, There are downloads for the many architectures on the package's page. Choose which one you need and download. I have tested this on i386 and amd64 architectures with identical errors. https://packages.debian.org/testing/squid3 https://packages.debian.org/testing/c-icap As you suspect, squidclamav is compiled on the server. If it makes a difference, I did use the package checkinstall to create a deb for squidclamav rather than the standard make install step. 1. ./configure --with-c-icap=/usr/bin/c-icap --prefix=/usr --libexecdir=/usr/share --sysconfdir=/etc 2. make 3. checkinstall --install=no Dale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
On 09/09/2014 8:57 AM, Mathieu Parent (Debian) wrote: Hello all, 2014-09-08 22:59 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: On 09/08/2014 3:24 PM, Gilles Darold wrote: Le 08/09/2014 19:31, Dale Schroeder a écrit : It looks like I have found the culprit, and it seems to be specific to users of squidclamav, like me. If I comment the following lines in squid.conf, then squid3 starts and restarts with no errors. icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_resp allow all So, there now appears to be a conflict of some sort between squidclamav and squid3. I have tried with squidclamav versions 6.10 and 6.11, having identical results. I've copied the squidclamav developer on this message to see if the cause of the problem can be determined. Thanks. Dale Hi, I'm the maintainer of SquidClamav and I'm afraid that the culprit is not the one you are suspecting or at least it is not so obvious. I have a VM with squid3 3.3.8-1 and SquidClamav 6.11, I used it a few days ago to test icap service chaining with qlproxy. Everything works great, I'm able to watch a web TV stream scanned by clamd through SquidClamav. I have run logrotate and stop/start squid3 manually but I'm not able to reproduce your issue. There's some differences with your installation : * even if the base is a Debian jessie/sid this is an Ubuntu server distribution * I have not updated squid to 3.3.8-1.2 * I've run c-icap + squidclamav on an other server. Ok I know that's not really helpful. Let me install c-icap on the server with squidclamav. Done. Using c-icap 0.3.4 and SquidClamav 6.11 installed on the same server than squid doesn't change anything, I'm still able to watch the web TV. Of course when I stop squid3, the service is interrupted but after restarting squid I don't any segfault in the logs. So I hope you are agree that SquidClamav is not the culprit in your bug. What is your version of c-icap ? Note that if you are using c-icap 0.1.6, it will not works with SquidClamav. Let me known if/how I can help more. Regards, Gilles, Thank you for replying. Obviously, you are correct in that c-icap is also involved. Perhaps Jessie's versions of squid3 and c-icap do not cooperate with each other. I cannot say, as there are no other entries in the logs other than what I posted in my initial bug report. Since the config lines I disabled were about squidclamav, I made the deduction that it was the problem, and the assumption I made may not be correct. The evidence you have provided is quite compelling. c-icap is version 0.3.4-1 squid is version 3.3.8-1.2 squidclamav is version 6.11 As Debian no longer has squidclamav in its repositories, it may be difficult to find a solution, but I will add c-icap's maintainers to this thread to see if any are willing to look at this for potential conflicts. Thanks again. Dale Schroeder I don't use squidclamav. Can you install squid3-dbg (and gdb) and run squid3 under gdb to see were the bug is. Squid3 in sid has not been updated since a while. I hope it will happen before jessie! Regards squid3-dbg and gdb64 are now installed. This is new territory for me. Would you please supply the steps/commands needed to do this? Thanks. Dale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
On 09/09/2014 8:57 AM, Mathieu Parent (Debian) wrote: Hello all, 2014-09-08 22:59 GMT+02:00 Dale Schroeder d...@briannassaladdressing.com: On 09/08/2014 3:24 PM, Gilles Darold wrote: Le 08/09/2014 19:31, Dale Schroeder a écrit : It looks like I have found the culprit, and it seems to be specific to users of squidclamav, like me. If I comment the following lines in squid.conf, then squid3 starts and restarts with no errors. icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_resp allow all So, there now appears to be a conflict of some sort between squidclamav and squid3. I have tried with squidclamav versions 6.10 and 6.11, having identical results. I've copied the squidclamav developer on this message to see if the cause of the problem can be determined. Thanks. Dale Hi, I'm the maintainer of SquidClamav and I'm afraid that the culprit is not the one you are suspecting or at least it is not so obvious. I have a VM with squid3 3.3.8-1 and SquidClamav 6.11, I used it a few days ago to test icap service chaining with qlproxy. Everything works great, I'm able to watch a web TV stream scanned by clamd through SquidClamav. I have run logrotate and stop/start squid3 manually but I'm not able to reproduce your issue. There's some differences with your installation : * even if the base is a Debian jessie/sid this is an Ubuntu server distribution * I have not updated squid to 3.3.8-1.2 * I've run c-icap + squidclamav on an other server. Ok I know that's not really helpful. Let me install c-icap on the server with squidclamav. Done. Using c-icap 0.3.4 and SquidClamav 6.11 installed on the same server than squid doesn't change anything, I'm still able to watch the web TV. Of course when I stop squid3, the service is interrupted but after restarting squid I don't any segfault in the logs. So I hope you are agree that SquidClamav is not the culprit in your bug. What is your version of c-icap ? Note that if you are using c-icap 0.1.6, it will not works with SquidClamav. Let me known if/how I can help more. Regards, Gilles, Thank you for replying. Obviously, you are correct in that c-icap is also involved. Perhaps Jessie's versions of squid3 and c-icap do not cooperate with each other. I cannot say, as there are no other entries in the logs other than what I posted in my initial bug report. Since the config lines I disabled were about squidclamav, I made the deduction that it was the problem, and the assumption I made may not be correct. The evidence you have provided is quite compelling. c-icap is version 0.3.4-1 squid is version 3.3.8-1.2 squidclamav is version 6.11 As Debian no longer has squidclamav in its repositories, it may be difficult to find a solution, but I will add c-icap's maintainers to this thread to see if any are willing to look at this for potential conflicts. Thanks again. Dale Schroeder I don't use squidclamav. Can you install squid3-dbg (and gdb) and run squid3 under gdb to see were the bug is. Squid3 in sid has not been updated since a while. I hope it will happen before jessie! Regards Here's a picture of the screen when I type run squid3 under gdb If I did my research correctly, here's the backtrace output: #0 0xb7fde424 in __kernel_vsyscall () #1 0xb792f267 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7930923 in __GI_abort () at abort.c:89 #3 0x801312f4 in xassert (msg=0x803d4c28 size == StrPoolsAttrs[i].obj_size, file=0x803dbf5c mem.cc, line=281) at debug.cc:565 #4 0x801cc057 in memFreeString (size=529, buf=0xb7aa8450 main_arena+48) at mem.cc:281 #5 0x8020892a in String::clean (this=0x80650fd4) at String.cc:159 #6 0x80341e4c in Adaptation::AccessRule::~AccessRule (this=0x80650fd0, __in_chrg=optimized out) at AccessRule.cc:15 #7 0x80342cc5 in Adaptation::Config::FreeAccess () at Config.cc:370 #8 0x803430a4 in Adaptation::Config::freeService (this=0x80645e00 Adaptation::Icap::TheConfig) at Config.cc:177 #9 0x803430f8 in Adaptation::Config::~Config (this=0x80645e00 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:396 #10 0x8035d914 in Adaptation::Icap::Config::~Config (this=0x80645e00 Adaptation::Icap::TheConfig, __in_chrg=optimized out) at Config.cc:54 #11 0xb7932081 in __run_exit_handlers (status=status@entry=0, listp=0xb7aa83c4 __exit_funcs, run_list_atexit=run_list_atexit@entry=true) at exit.c:82 #12 0xb79320dd in __GI_exit (status=0) at exit.c:104 #13 0x801c951f in watch_child (argv=optimized out) at main.cc:1679 #14 SquidMain (argc=2, argv=0xb7d4) at main.cc:1441 #15 0x800cd089 in SquidMainSafe (argv=0xb7d4, argc=2) at main.cc:1242 #16 main (argc=2, argv=0xb7d4) at main.cc:1234 Hope this helps. Dale
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
It looks like I have found the culprit, and it seems to be specific to users of squidclamav, like me. If I comment the following lines in squid.conf, then squid3 starts and restarts with no errors. icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_resp allow all So, there now appears to be a conflict of some sort between squidclamav and squid3. I have tried with squidclamav versions 6.10 and 6.11, having identical results. I've copied the squidclamav developer on this message to see if the cause of the problem can be determined. Thanks. Dale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
Le 08/09/2014 19:31, Dale Schroeder a écrit : It looks like I have found the culprit, and it seems to be specific to users of squidclamav, like me. If I comment the following lines in squid.conf, then squid3 starts and restarts with no errors. icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav adaptation_access service_resp allow all So, there now appears to be a conflict of some sort between squidclamav and squid3. I have tried with squidclamav versions 6.10 and 6.11, having identical results. I've copied the squidclamav developer on this message to see if the cause of the problem can be determined. Thanks. Dale Hi, I'm the maintainer of SquidClamav and I'm afraid that the culprit is not the one you are suspecting or at least it is not so obvious. I have a VM with squid3 3.3.8-1 and SquidClamav 6.11, I used it a few days ago to test icap service chaining with qlproxy. Everything works great, I'm able to watch a web TV stream scanned by clamd through SquidClamav. I have run logrotate and stop/start squid3 manually but I'm not able to reproduce your issue. There's some differences with your installation : * even if the base is a Debian jessie/sid this is an Ubuntu server distribution * I have not updated squid to 3.3.8-1.2 * I've run c-icap + squidclamav on an other server. Ok I know that's not really helpful. Let me install c-icap on the server with squidclamav. Done. Using c-icap 0.3.4 and SquidClamav 6.11 installed on the same server than squid doesn't change anything, I'm still able to watch the web TV. Of course when I stop squid3, the service is interrupted but after restarting squid I don't any segfault in the logs. So I hope you are agree that SquidClamav is not the culprit in your bug. What is your version of c-icap ? Note that if you are using c-icap 0.1.6, it will not works with SquidClamav. Let me known if/how I can help more. Regards, -- Gilles GPL tools at http://www.darold.net/ (squidclamav - sendmailanalyzer - ora2pg - modproxyhtml - pgCluu squidguardmgr - sysusage - squidanalyzer - pgbadger - pgformatter) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760303: squid 3.3.8-1.2 segfaults during initscript start/restart
Now, in addition to the sefault during startup, log rotation is failing with the following error message: /etc/cron.daily/logrotate: 2014/09/05 06:25:08| assertion failed: mem.cc:281: size == StrPoolsAttrs[i].obj_size Aborted error: error running shared postrotate script for '/var/log/squid3/*.log ' run-parts: /etc/cron.daily/logrotate exited with return code 1 In spite of the error message, I do get new log files each day - very strange. Dale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
