www/squid does not shutdown via rc

[Michelle Sullivan]

Kevin Oberman wrote:
> On Mon, Jan 26, 2015 at 2:56 PM, Dr. Peter Voigt <pvoigt at uos.de> wrote:
>
>   
>> On Mon, 26 Jan 2015 21:25:14 +0100
>> Marko Cupać <marko.cupac at mimar.rs> wrote:
>>
>>     
>>> On Mon, 26 Jan 2015 16:20:46 +0000
>>> Matthew Seaman <matthew at 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/