Scenario: - squid-3.4.9_1 and adzap-20110915_1 are installed - After starting squid, the PID in the pid file points to squid's first child process: [0]# cat /var/opt/squid/run/squid.pid 62002 [0]# pstree | grep squid | \--- 62371 root grep squid |-+= 62000 squid /usr/local/sbin/squid -f /etc/opt/squid/squid.conf | \-+- 62002 squid (squid-1) -f /etc/opt/squid/squid.conf (squid) | |--- 62003 squid (unlinkd) (unlinkd) | |--- 62004 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | |--- 62005 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | |--- 62006 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | |--- 62130 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | |--- 62131 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | |--- 62132 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | |--- 62133 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | |--- 62134 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | |--- 62135 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect | \--- 62136 squid /usr/local/bin/perl5.18.4 -w /usr/local/libexec/squid_redirect [0]# Problem: - Executing "service squid stop" initially stops process 62002 (the first child process) and all its children, as a side effect producing a core dump in the cache directory. Immediately thereafter, the process is restarted again, with a new PID which is duly recorded in the pid file, and spawning all the other subprocesses (squid_redirect). Expected outcome: - After executing above command, squid should shut down completely, and no core dump should be produced.
I now believe that this is actually not a bug in squid, but rather the base system, because this behavior has started with the upgrade of the base system from 9.2 to 10.1. Note that with this upgrade, all ports have been recompiled. What seems to happen is that instead of exiting normally, the squid child process dumps core with signal 6. There is another utility which now also regularly dumps core on exit: etherape, but this one always with signal 11. All of this is happening on a rather old (year 2000) computer sporting an Athlon processor: FreeBSD 10.1-RELEASE #0 r274437M: Sun Nov 30 09:34:53 CET 2014 root@v905.xyzzy:/.../hal/z/OBJ/FreeBSD/i386/releng/10.1/sys/XYZZY i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD Athlon(tm) Processor (807.21-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Family = 0x6 Model = 0x4 Stepping = 2 Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR> AMD Features=0xc0440800<SYSCALL,<b18>,MMX+,3DNow!+,3DNow!> real memory = 1342177280 (1280 MB) avail memory = 1303310336 (1242 MB) I suspect that this is actually a library or compiler problem of the base system.
Hmmm... recompiling with USE_GCC=yes results in the same behavior (core dump + restart of squid by the parent process)
kib@ committed two fixes to stable/10 on 05.12.2014 which are supposed to fix this.
I only found r275502. Is that it? If yes, I'll apply it to releng/10.1 and inform you about the results. Thanks anyway for the quick reply. -- Martin
Following the recommendation by Florian, I applied r275456 and r275502 to releng/10.1, and the problem is indeed gone. Discussion can be found in http://lists.freebsd.org/pipermail/freebsd-threads/2014-November/005611.html (also pointed out by Florian). Thanks for the help. -- Martin p.s. Since this is a rather serious problem, it would be nice to include it in releng/10.1 also upstream (i.e. in addition to the security patches this branch now receives).
Created attachment 154031 [details] single patch file combining r275456 and r275502 for FreeBSD 10.1-RELEASE p6 Being not that familiar with the source layout of FreeBSD, I spent the whole morning in order to find the relevant patches r275456 and r275502 that as a MATTER OF FACT solve the present squid issue on 10.1-RELEASE. In order to facilitate future references, here come the links: https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_sig.c?r1=270788&r2=275456&view=patch https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_sig.c?r1=275456&r2=275502&view=patch I attach to this comment a file combining both above patches into one single patch file suitable for FreeBSD 10.1-RELEASE p6.