www/squid does not shutdown via rc

[Kevin Oberman]

On Mon, Feb 2, 2015 at 11:00 AM, Nick Rogers <ncrogers at gmail.com> wrote:

>
>
> On Fri, Jan 30, 2015 at 8:51 PM, Kevin Oberman <rkoberman at gmail.com>
> wrote:
>
>> On Wed, Jan 28, 2015 at 6:58 AM, Dr. Peter Voigt <pvoigt at uos.de> wrote:
>>
>> > On Tue, 27 Jan 2015 11:51:51 +0100
>> > Marko Cupać <marko.cupac at mimar.rs> wrote:
>> >
>> > > On Tue, 27 Jan 2015 07:11:10 +0000
>> > > Matthew Seaman <matthew at FreeBSD.org> wrote:
>> > >
>> > > > On 2015/01/27 03:52, Kurt Jaeger wrote:
>> > > > > Doesn't installing a custom kernel break freebsd-update ?
>> > > >
>> > > > No.  freebsd-update has always supported using a custom kernel.  It
>> > > > helps if you name your kernel something other than GENERIC, which
>> > > > you do by creating a modofoed kernel config file
>> > > > in /usr/src/sys/amd64/conf (or i386 if that's your architecture):
>> > > > eg.
>> > > >
>> > > > % cat FOO
>> > > > include GENERIC
>> > > >
>> > > > ident FOO
>> > > >
>> > > > and then add:
>> > > >
>> > > > KERNCONF=   FOO
>> > > >
>> > > > to /etc/make.conf
>> > > >
>> > > > You should also edit /etc/freebsd-update.conf and change the
>> > > > 'Components' line to remove 'kernel' from the list.
>> > > >
>> > > > None of this is absolutely necessary, but it will help you avoid
>> > > > accidentally ending up with the generic kernel.
>> > > >
>> > > > In any case, what you will need to do is rebuild your kernel and
>> > > > reinstall it any time freebsd-update touches the kernel.  You can
>> > > > use freebsd-update to maintain the kernel sources, which will pull
>> > > > in the needed updates to the kernel sources.
>> > >
>> > > The timing for this is really unfortunate for me, because I have just
>> > > re-installed my FreeBSD fleet of some 20 virtual servers without
>> > > sources included, and I just introduced "binary only" policy (ok I do
>> > > build my own ports on one server in poudriere, but all other servers
>> > > use packages).
>> > >
>> > > I guess theoretically it is possible to make "kernel build server"
>> > > which will build custom kernel for distribution to other servers. I
>> > > am just not sure how will RELEASE userland tolerate STABLE kernel.
>> > >
>> > > Does this sound reasonable? Any tips?
>> > >
>> > > Thank you in advance,
>> >
>> > Thanks to all who contributed to this thread.
>> >
>>
>> Sorry for the late response. I've had guests for hte past few days and
>> simply have not had time to properly address your concerns.
>>
>> While most of these concerns are not an issue, exactly why gets a bit more
>> complex. And there are some real issues, but this is an exceptionally
>> simple case and eliminates most of them. See comments in-line.
>>
>> >
>> > @Kevin:
>> > Your outline of kernel patching procedure is helpful and corresponds
>> > in most aspects what I have thought so far. I aggree with you that
>> > patching, building and installing a custom kernel can be managed. And I
>> > am sure that I can do it.
>> >
>> > So getting a custom kernel installed is one thing but keeping your
>> > system in a manageable way is another. Kurt and Mattew pointed out that
>> > you want to keep freebsd-update working in a reliable way and this
>> > obviously needs some manual interaction. Information about it is
>> > not too easily gathered and answers given here still leave some
>> > question open to me.
>> >
>>
>> It does, but very little. In general, freebsd-update is a binary update
>> tool. While it does update sources, if they are present, it makes no use
>> of
>> those sources.
>>
>> My instructions provided for saving the GENERIC kernel where
>> freebsd-update
>> will use it instead of the running kernel. /boot/GENERIC is used only be
>> freebsd-update. It is otherwise unneeded. This does not touch any files
>> that will normally require merging, which is often the main complication.
>> I
>> am unsure whether it will require a merge of the modified source files,
>> but
>> that is easily avoidable renaming /sys/kern/kern_sig.c.orig to overwrite
>> the patched /sys/kern/kern_sig.c file, returning the sources to their
>> original condition.
>> # cp /sys/kern/kern_sig.c.orig /sys/kern/kern_sig.c
>>
>> This is not really required, but will assure that, from the perspective of
>> freebsd-update, the system will be entirely unchanged. There is simply no
>> impact on future updates as there are no changes left.
>>
>>
>> > I have had a hard time with freebsd-update when upgrading 10.0-RELEASE
>> > -> 10.1-RELEASE:
>> >
>> >
>> https://forums.freebsd.org/threads/segmentation-fault-while-upgrading-from-10-0-release-to-10-1-release.48977/page-2#post-277094
>> > and I do not want to get even more trouble letting
>> > freebsd-update confuse my system with a mixture of GENERIC and custom
>> > kernels ending in a situation where none of them is able to boot.
>> >
>> > I have learned that I can advice freebsd-update to not update my kernel
>> > but am still confused whether it is the version under /boot/GENERIC or
>> > the one under /boot/kernel. And I would like to know how to tell
>> > FreeBSD how to boot a certain kernel. All I know so far is that if a
>> > kernel fails to boot you have to boot into recovery and move kernel.old
>> > to kernel. Is there a boot menu available with the FreeBSD boot loader
>> > which would simplify life a lot?
>> >
>>
>> The running kernel is in boot/kernel. /boot/GENERIC is not present unless
>> you create it and, when present, it is used as the kernel which
>> frebsd-update will patch in the upgrade phase and then install in the
>> install phase. Actually, the Handbook recommends always keeping a copy of
>> the GENERIC kernel as /boot/GENERIC. There is no reason not to allow
>> freebsd-update to update the kernel as it will use /boot/GENERIC and
>> ignore
>> the running /boot/kernel/kernel.
>>
>
> Should /boot/GENERIC be a directory containing the contents of the default
> RELEASE kernel (i.e., a copy of /boot/kernel, including
> /boot/kernel/kernel, modules, and symbols) OR the actual kernel file itself
> (i.e., a copy of /boot/kernel/kernel)?
>

It should be the kernel file, itself. Copy /boot/kernel/kernel to
/boot/GENERIC. If you have a modified kernel you can grab the release
kernel from a memstick or other distro. I think the Handbook covers it. I
really recommend reading the freebsd-update section before messing with
this stuff. It's not terribly long, but provides more detailed information
on how to use it than the man page which is more technical and rather terse.

Note that this allows freebsd-update to deal with custom kernels, but not
code mods to things that go into modules.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com