# Uptime



## ZFS_HBG (Jun 30, 2021)

Hi 

Correct me if i am wrong but:
I have experienced that a new kernel.ko comes with nearly every patch update. 
So if you want to keep you system up to date you will need to reboot your system every time a new kernel.ko comes, which is around every 90 day or so.
This results in a max uptime of around 90 day before you have to reboot to get the new kernel patch in to your system.

Have i got this totally wrong?


----------



## mer (Jun 30, 2021)

If you apply updates every 90 days and reboot, then your max uptime is 90 days.
If you are using ZFS, apply the update into a new boot environment, activate the new BE and don't reboot, you'll get longer uptimes but the patches won't be effective until you reboot.

So, just like every system ever, updating may require a reboot so you need to weigh the tradeoffs:  is this update critical to my system?  If the answer is yes, apply and reboot and ignore uptime.  If the answer is no, apply don't reboot until it's more convenient and preserve your uptime.

But pretty much if it's a security related update and affects the kernel or modules, apply reboot.  Uptime is irrelevant against a security hole.


----------



## Alain De Vos (Jun 30, 2021)

Unupdated installations become over time unmanagable. 
Because then at one time you must do all the small and large updates.
And if one update fails it is painfull.


----------



## sko (Jul 1, 2021)

If patches don't affect your usecase you could safely skip them and wait until the next batch of updates; i.e. the latest erratas from a few days ago are quite specific and can be safely skipped e.g. if you don't run ipfw or don't plan to update that host from 12.2 to 13.0 (vlan patch).

I have some openBSD routers and route reflectors running with uptimes currently hitting ~1 year or more. Yes, there were security-related patches and changes in the meantime, but none of them affected their use case (e.g. only peering and route distribution via openBGPd and some forwarding/NATing via PF) or were against the base system (e.g. network stack). Especially the router VMs usually don't get updated anyways, due to the downtime this causes - they are just being replaced by a new installation because their configuration is quite minimal, can be easily automated and a minimal openBSD install (without x*) takes ~3-5 minutes max. Thanks to CARP, downtime for routers is practically non-existent this way (and for BGP it doesn't matter as we have redundant peering and reflectors...).
*BUT* you HAVE to carefully monitor all patches and version updates and their changelogs so you won't miss any critical updates.


----------



## SirDice (Jul 1, 2021)

ZFS_HBG said:


> This results in a max uptime of around 90 day before you have to reboot to get the new kernel patch in to your system.


Uptimes are overrated. There's nothing wrong with a reboot.


----------



## sko (Jul 1, 2021)

SirDice said:


> Uptimes are overrated. There's nothing wrong with a reboot.


+1
exacly this.

if you have to fulfill some arbitrary availability numbers, go for redundancy, not for maximum uptime of single systems (which are single point of failures anyways...)


----------



## SirDice (Jul 1, 2021)

sko said:


> if you have to fulfill some arbitrary availability numbers, go for redundancy, not for maximum uptime of single systems (which are single point of failures anyways...)


Yes, exactly. You guarantee the uptime of a _service_ not a _server_. And even with 99.999% guaranteed uptime there's room for some down time.


----------

