From owner-freebsd-ports@FreeBSD.ORG Tue Jan 27 03:39:34 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D780C44C for ; Tue, 27 Jan 2015 03:39:34 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id BFB79167 for ; Tue, 27 Jan 2015 03:39:34 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NIT00B6RE9RBR00@hades.sorbs.net> for freebsd-ports@freebsd.org; Mon, 26 Jan 2015 18:44:17 -0800 (PST) Message-id: <54C6FA5D.4070902@sorbs.net> Date: Tue, 27 Jan 2015 03:39:25 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Kevin Oberman Subject: Re: www/squid does not shutdown via rc References: <20150126152433.52f07277f377f9396b65c9a8@mimar.rs> <20150127.002919.335530336.yasu@utahime.org> <20150126163934.32f199d43d86a70b00dd7e4a@mimar.rs> <20150127.010539.230444205.yasu@utahime.org> <54C6695E.6010704@freebsd.org> <20150126212514.56c8f0866f1d63bb98089dd0@mimar.rs> <20150126235655.5d371915@kirk.drpetervoigt.private> In-reply-to: Cc: FreeBSD Ports ML , "Dr. Peter Voigt" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 03:39:35 -0000 Kevin Oberman wrote: > On Mon, Jan 26, 2015 at 2:56 PM, Dr. Peter Voigt wrote: > > >> On Mon, 26 Jan 2015 21:25:14 +0100 >> Marko Cupać wrote: >> >> >>> On Mon, 26 Jan 2015 16:20:46 +0000 >>> Matthew Seaman wrote: >>> >>> >>>>>>> Also, is there a chance they will be pushed to freebsd-update? >>>>>>> >>>> No. Unless these are either security fixes or fixes for a major >>>> regression (which this is not) in 10.1-RELEASE, then they won't be >>>> applied to that branch. >>>> >>> From OS point of view, this could be indeed seen as minor regression. >>> >>> But please consider server admin's point of view: >>> - squid33 had latest release on 2014-08-27 >>> - squid33 has been scheduled for expiration on 2015-01-31, but was >>> extended to 2015-05-31 because of ntlm_auth issue in squid34 >>> - squid34 does not run on 10.1-RELEASE-pX >>> - 10.2-RELEASE is not likely to be before 2015-05-31 >>> >>> Which means that pkg installs of latest squid (www/squid34) will be >>> useless on latest FreeBSD release (10.1-RELEASE) for a long time. >>> >>> >>>> They will, however, be in the next release cut from stable/10, which >>>> will be 10.2-RELEASE, and presumably in releases from other branches >>>> from now on. >>>> >>>> Your best recourse at the moment is to manually patch the kernel >>>> sources and build yourself a custom kernel on the affected machines. >>>> >>> I was looking forward to avoid it. Perhaps I'm succumbing to >>> conformism. >>> >> I am suffering from the same 10.1/Squid problem for some time and I am >> glad stumbling across this thread. Fortunately Squid is running stable >> apart from this shutdown issue. >> >> To me it looks like a serious kernel issue and I can hardly believe it >> will not be fixed in the 10.1-RELEASE. >> >> It is quite an effort to compile, manually patch and install a custom >> kernel, if you aren't too experienced like I am. I have only managed >> building the GENERIC kernel so far as part of the build world process >> when upgrading to 10.1. >> >> While I can sympathize with those hitting this bug, shortly after a >> > release FreeBSD support is turned over to the Security Officer and it is > very difficult to get it pulled back. The fear that a change will break > other stuff is too great, so it's very unlikely to happen for anything that > is not: > 1) A security issue > 2) Causes the base system to have serious stability issues > > Painful as this may be to squid users, it is just not at the level a a > release re-roll. > > As far as patching, it is really pretty easy and requires no special skills > or knowledge. > > 1. Download the two patches as ~/A.patch and ~/B.patch > 2. Apply them to the source > # cd /usr/src > # patch -p2 < ~/A.patch > # patch -p2 < ~/B.patch > 3. Save your existing kernel for future updates (security patches or 10.2) > # cp /boot/kernel/kernel /boot/GENERIC > 4. Rebuild the kernel > # make buildkernel (If you have multiple cores, the kernel will build > much faster if you add he '-jN' option where 'N' is 1 or two more than the > number of cores) > 5. Install the new kernel > # make installkernel > 6. Reboot to start the new kernel > > Seriously Kevin? (and by that I know it's only 6 'easy' steps, however you seem (like other) to be forgetting... FreeBSD Users are not FreeBSD developers....!) -- Michelle Sullivan http://www.mhix.org/