Reduce restarts during maintenance: Update HaOS, Home Assistant, Add-ons but defer restarts until reboot

Feature Requests
1

WTH Summary: WTH do I have to restart Home Assistant (and connected networks like Z-wave, Zigbee, and Thread) multiple times in order to bring everything up to date when there are updates available for Home Assistant, HaOS, Add-ons, and on VMs, the host system/hypervisor.

Feature Request–Allow updates to be installed/staged but defer the activation of those updates until the user is ready to reboot (or restart the necessary components).

This is really 3 related feature requests in one:

  • Feature Request 1: Ability to update Home Assistant without an immediate restart.
  • Feature Request 2: Ability to update Add-on containers without an immediate restart of the add-on.
  • Feature Request 3: Ability to update HaOS without an immediate reboot.

Benefits–This will allow users to reduce the amount of downtime and restarts during periodic system maintenance. Additionally, a number of questions about the order of applying updates and whether there any dependencies between components that need one component updated before another can be reduced or eliminated by only restarting after all the desired components have been updated.

Use case 1

  1. Install/stage updates for Home Assistant and any desired add-on updates without restarting.
  2. Install HaOS update and allow the HaOS update to reboot with the result that everything is restarted with the newly installed versions.

This process would likely be used when HaOS is installed on physical hardware or there is no maintenance that needs to be done on the physical host system.

Use case 2

Similar to above but allow for maintenance that needs to occur on a physical host system without additional restarts:

  1. Install/stage updates for Home Assistant and any desired add-on updates without restarting.
  2. Install/stage HaOS update but do not restart
  3. Shutdown HaOS
  4. On the host (physical) system apply updates to the OS, kernel, hypervisor, storage, etc.
  5. Reboot the host physical system, so that everything will start up fresh with the newly installed updates.

Motivation–While some users may actively apply any update as soon as it is available, other users may prefer to only update their Home Assistant installation a regular schedule such a monthly cadence in the belief that it will reduce downtime and increase stability.

Motivation for use case 2–According to Home Assistant analytics, VM installations of Home Assistant are one of the largest groups. As mentioned in the 2024.2 release party, VM installs (32.6%) passed RPI 4 installs (32.56%). So there is additional incentive to make sure there isn’t too much downtime while trying to update the full stack.

I understand there are risks with updating too many things at once and then not being able to tell what caused things to break, but if I’m aware of the risks and want to take them that should be up to me. Also note, this a similar case to a user reinstalling Home Assistant from a backup.

If this is considered an advanced feature, I’d be happy to just have access from the CLI and envision something like this:

# ssh hassvm 
$ ha core update --no-restart
$ ha os update --no-restart
$ ha addon update foo --no-restart
$ ha addon update bar --no-restart
$ ha host shutdown 

# # ----- back on physical host after the ssh has exited ----
# apt full-upgrade # do host system/hypervisor updates,
# reboot  # host system
2

That won’t get you far on HAOS.

3

That won’t get you far on HAOS.

Yes you are correct, especially since the preceding command was ha host shutdown.

I guess I should have been clearer that was an example of updating the physical system’s OS, not the Hass VM’s HaOS.

4

I don’t ever remember having to do this. The containers need to restart, not Home Assistant.

And what about the ~2-3 minute restart process (in a vm) is a burden?
I am interested in knowing.

5

I suspect from the wording of the request, it becomes burdensome if you have to do it a number of times in 1 session.

6

If I understand the issue, I’ve found this frustrating, too. I don’t jump on every point version update. Often, when I do go to update HA Core, there’s an HA OS update available, too. I never know which one I should do first. It would be nice to “stage” the Core update, then let it take effect when the OS restarts after updating that.

7

That is exactly my point!

Additionally there are times when certain Add-ons updates are prerequisites before updating to the latest Home Assistant Core release. This happens with ZwaveJS UI. (I haven’t jumped on the Matter bandwagon but I suspect that case happens there too.)

I update my main Home Assistant installation pretty conservatively—usually 1-2 weeks after the main release when the churn has slowed and we up to something like a .3 release that can typically run for the next month.

@Sir_Goodenough asked why this is “such a burden”: by the time I’ve updated add-ons, Home Assistant Core, HaOS, and the host system OS/hypervisor, Hone Assistant will have been restarted 3 times. (My Zwave network will have restarted 4 times if that add-on needed an update.)

I didn’t think I’d have to say this here, but that’s a very manual process with a lot of clicking, watching, and waiting. It needs to be scheduled when it isn’t going to be a problem that all the things Home Assistant does aren’t going to be missed.

1 Like
8

I rewrote the feature request based on the discussion so far. Hopefully it is clearer.

1 Like
9

I’ve never had to restart Home Assistant after installing add-ons; they generally restart themselves automatically. It’s only when the OS, Supervisor, or Core need updated that I have to do so.

1 Like
10

May I suggest this…
I see where you are going…
Add a button in the hamburger menu to update everything that is available. It would pop links to the changes on the screen that you could optionally review, then update everything on the available updates list in the optimal order.
Then you don’t have to worry about the order, not that I think it actually matters 99% of the time.

Personally I just click yes on the add-ons and the HACS items (and then the ESPhome half hour rebuilding festival), I look over the HAOS and HA changes and send them one at a time any order when the other stuff is done because I’m afraid the reboot will mess up the other updates…

11

If we’re imaging how this might look in the UI, here’s my suggestion:

When you do any update, there’s a check box to Create backup before updating.

I imagine another check box for restarting when done. It would be checked by default, but could be un-checked if the user wants to do another update before restarting.

1 Like
12

First, I didn’t put anything about UI in this feature request because I just wanted to get the necessary functionality described that would allow restarts to be deferred. I’d be happy to just get the --no-restart option added to the CLI. (Also UI discussions can take on a life of their own…)

That being said, what you describe nicely adds the requested functionality with minimal UI changes.

Another UI model would be something more like HACS. For integrations, HACS lets you pull down the updated code and gives a big “Pending Restart” banner until you actually restart Home Assistant. You can update a number of integrations and HACS itself with a single restart. I believe this is somewhat the UI that @Sir_Goodenough is describing.

HACS would be much more tedious to use if worked like Home Assistant–where you have no choice other than immediately restarting Home Assistant after each updated integration is pulled down.

1 Like
13

I don’t think I implied anywhere that Home Assistant needed to be restart after updating add-ons. The idea I’d like to stage the add-on update (pull down the image, do whatever is necessary with tags or other pointers to make sure the right image gets started), but not actually kill and restart the container because that’s unnecessary work if I’m going to restart HaOS when everything is done.

For many small add-ons this might not seem to matter much. But if you take something like the Zwave JS UI add-on and a reasonable number of Zwave devices (I have 30-40) it takes a while and there is a lot of Zwave network traffic as it has to poll every device for current state to see if anything changed while it was being restarted. If you have any battery powered devices, there is additional time until these wake up and respond.

I don’t know about the percentage, but there have been times when the ordering matters because the integration inside of Home Assistant has been updated and the release notes say you need to upgrade the add-on as well. This is most likely to happen with things like Matter and ZwaveJS UI where the service is essentially provided by an integration and an add-on working together.

When I’m doing that, I’m wondering why for something that’s supposed to be about automation, that we should we rely on users to spend time manually managing those processes and making good decisions about ordering.

I generally manually serialize add-on updates because I don’t know if it is safe–ie won’t cause too much thrashing/be an I/O bottleneck that would interfere with database/file system access by Home Assistant.