Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jan 2015 03:39:25 +0100
From:      Michelle Sullivan <michelle@sorbs.net>
To:        Kevin Oberman <rkoberman@gmail.com>
Cc:        FreeBSD Ports ML <freebsd-ports@freebsd.org>, "Dr. Peter Voigt" <pvoigt@uos.de>
Subject:   Re: www/squid does not shutdown via rc
Message-ID:  <54C6FA5D.4070902@sorbs.net>
In-Reply-To: <CAN6yY1uciVB-83=ECbrtdnNOFDs3VCX9UA97thK8mQ08aavHtw@mail.gmail.com>
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> <CAN6yY1uciVB-83=ECbrtdnNOFDs3VCX9UA97thK8mQ08aavHtw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote:
> On Mon, Jan 26, 2015 at 2:56 PM, Dr. Peter Voigt <pvoigt@uos.de> wrote:
>
>   
>> On Mon, 26 Jan 2015 21:25:14 +0100
>> Marko Cupać <marko.cupac@mimar.rs> wrote:
>>
>>     
>>> On Mon, 26 Jan 2015 16:20:46 +0000
>>> Matthew Seaman <matthew@freebsd.org> 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/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54C6FA5D.4070902>