[OpenIndiana-discuss] updates and reboots

[Richard L. Hamilton]

> On Jan 7, 2024, at 22:07, Goetz T. Fischer <g.fischer at r-a-c.de> wrote:
> 
> hi,
> 
> a general question:
> 
> i did a "pkg update" on the 2nd and another one just now. so just a few days later but again a new be 
> was created and i had to reboot. of course i understand that for certain things a reboot is necessary 
> but is there a way to somewhat filter the things that don't need a reboot ?
> for a desktop system that doesn't matter but i can't reboot a server once a week or maybe even more 
> often. especially if i have several zones and/or vms. in other words, what's the "officially" 
> recommended way of updating a server?
> 
> thanks in advance for any info


While OI doesn't support hot kernel patching AFAIK (like some Linux, or like Solaris occasionally did), not all updates create a new BE (unless one requested a backup BE).

What can be changed safely without a new BE or reboot, and what can't, is subtle. It's quite possible that some individual package updates (and thus the most extreme requirement of a group of them) might be able to be redone so they don't require a new BE or reboot; but getting that reliably right isn't easy.

I don't know offhand what happens if you install an update that creates a new BE,  and without rebooting, install another. I would hope the newest BE created would include all the updates (so maybe you could delete the intermediate one to save space). How long you wait with the reboot is up to you. But some inconsistencies may exist, if for instance there are administrator-editable configuration files both in the running BE and in the new one, and you make changes, they probably won't get into the new BE. So you don't want to wait too long, and with multiple administrators, you want to make sure they're careful about that and know that there's a pending reboot to a new BE, and to defer configuration changes as much as possible. And of course some configuration changes add to the risk of boot problems.

If you need nonstop uptime, you need a cluster or the like, so you can update one at a time. And you need very strict configuration control, and probably a test system where all changes are tried first (isolated network, obviously dummy data, to avoid nasty confusion).

At least with BE's rather than old style patching, you can do the somewhat slow update anytime (give or take that it has some slight performance impact while running), do the relatively quick reboot at a time more convenient to the customers, and have an easy recover plan (switch back to the old BE) if something goes wrong.