Solved Does base patching require reboot?

I just patched from FreeBSD 11-p1 to p2 with freebsd-update fetch install and I was noticing that after OK patching uname -a was still showing p1 and upon reboot then I saw p2.
I am guessing this is due to kernel changes-the need to reboot? How do servers do it?
 
This bit from the manual is what I was wondering:
"Again, the system should be restarted if the kernel or any kernel modules were modified and any affected binaries should be restarted."

Is it safe to assume that most -RELEASE security patches involve kernel or modules and need reboot?
 
Is it safe to assume that most release security patches involve kernel or modules and need reboot?
Yes.

As far as I know there has been only a couple of tentative to make a kernel patchable without rebooting, "ksplice", later bought from Oracle, and "kGraft" from SuSE and RedHat.
 
Thanks that was ultimately was part of my question. Can you restart the kernel without rebooting.
 
Sorry I changed the phrasing to "kernel restart".

How do FreeBSD datacenters handle it? Staggered updates during slow time?
 
Right now I'm only running small servers and desktop systems, I will leave to others the answer about datacenters.
 
I am probably way out of my league, but I remember reading something in the Red Hat docs regarding patching a running kernel via compiled modules. Perhaps similar measures could be applied to the FreeBSD kernel?
Otherwise, I also do a full reboot after applying the updates via freebsd-update.
 
Is it safe to assume that most -RELEASE security patches involve kernel or modules and need reboot?
You should always read the security advisory before you run freebsd-update. It tells you exactly what is affected and if a reboot is required. If the update does not involve a kernel update, then there is no need to reboot.
 
How do FreeBSD datacenters handle it? Staggered updates during slow time?


It will depend upon the datacenter. Generally, you notify clients that may be affected, schedule it for the 23:00-7:00 or similar shift or have fallover servers so that service isn't impacted. For example, ServerX may have backup ServerY using carp so that while X is offline Y takes over.
 
Back
Top