supervisor
supervisor copied to clipboard
home-assistant
Supervisor keeps going “Unhealthy”
Describe the issue you are experiencing
I'm constantly having the supervisor going unhealthy. The following error, more exactly:
It points to the following help page, which offers a complicated solution for the problem: https://www.home-assistant.io/more-info/unhealthy/privileged
This issue blocks me from updating anything else in ha.
Workaround
After some research, I've found this talk: https://community.home-assistant.io/t/supervisor-keeps-going-unheathly-dropping-out-from-being-privileged/279706
The solution proposed there is executing sudo docker restart hassio_supervisor
This works, which tells me that there is nothing wrong in my installation except the supervisor getting a bit lost.
This is a bit depressing. In my case, it involves opening a sh session in my server to run it. I need also to have this solution saved for reference somewhere so I remember what to do in such recurring situation.
Also, the help page makes the problem even more scary than it is.
What type of installation are you running?
Home Assistant Supervised
Which operating system are you running on?
Debian 11
Steps to reproduce the issue
There is no specific way to reproduce it. It just happens... maybe after supervisor updates?
Anything in the Supervisor logs that might be useful for us?
Just got a truncated error trace at the top of the logs with the following, which seems to be unrelated:
File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 268, in token_validation
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/api/middleware/security.py", line 280, in core_proxy
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/api/utils.py", line 62, in wrap_api
answer = await method(api, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/api/store.py", line 178, in store_info
ATTR_ADDONS: [
^
File "/usr/src/supervisor/supervisor/api/store.py", line 179, in <listcomp>
self._generate_addon_information(self.sys_addons.store[addon])
File "/usr/src/supervisor/supervisor/api/store.py", line 114, in _generate_addon_information
ATTR_ADVANCED: addon.advanced,
^^^^^^^^^^^^^^
File "/usr/src/supervisor/supervisor/addons/model.py", line 227, in advanced
return self.data[ATTR_ADVANCED]
^^^^^^^^^
File "/usr/src/supervisor/supervisor/store/addon.py", line 19, in data
return self.sys_store.data.addons[self.slug]
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'a0d7b954_thelounge'
### System Health information
As described in the issue.
### Supervisor diagnostics
[config_entry-hassio-0f7faf0987dcd2404bcff3078d1bd5de.json.txt](https://github.com/home-assistant/supervisor/files/11749216/config_entry-hassio-0f7faf0987dcd2404bcff3078d1bd5de.json.txt)
### Additional information
_No response_
As requested, the system information:
System Information
| version | core-2023.6.1 |
|---|---|
| installation_type | Home Assistant Supervised |
| dev | false |
| hassio | true |
| docker | true |
| user | root |
| virtualenv | false |
| python_version | 3.11.3 |
| os_name | Linux |
| os_version | 5.10.0-9-amd64 |
| arch | x86_64 |
| timezone | Europe/Warsaw |
| config_dir | /config |
Home Assistant Community Store
| GitHub API | ok |
|---|---|
| GitHub Content | ok |
| GitHub Web | ok |
| GitHub API Calls Remaining | 4939 |
| Installed Version | 1.32.1 |
| Stage | running |
| Available Repositories | 1283 |
| Downloaded Repositories | 9 |
Home Assistant Cloud
| logged_in | false |
|---|---|
| can_reach_cert_server | ok |
| can_reach_cloud_auth | ok |
| can_reach_cloud | ok |
Home Assistant Supervisor
| host_os | Debian GNU/Linux 11 (bullseye) |
|---|---|
| update_channel | stable |
| supervisor_version | supervisor-2023.06.2 |
| agent_version | 1.2.2 |
| docker_version | 20.10.9 |
| disk_total | 108.0 GB |
| disk_used | 12.7 GB |
| healthy | failed to load: Unhealthy |
| supported | true |
| supervisor_api | ok |
| version_api | ok |
| installed_addons | Terminal & SSH (9.7.1), Mosquitto broker (6.2.1), Zigbee2MQTT (1.31.2-1), Node-RED (14.2.2), Z-Wave JS UI (1.13.4), File editor (5.6.0), Matter Server (4.6.0), Studio Code Server (5.6.1) |
Dashboards
| dashboards | 6 |
|---|---|
| resources | 6 |
| views | 6 |
| mode | storage |
Recorder
| oldest_recorder_run | June 8, 2023 at 11:07 |
|---|---|
| current_recorder_run | June 9, 2023 at 13:36 |
| estimated_db_size | 23.85 MiB |
| database_engine | sqlite |
| database_version | 3.41.2 |
This isn't a standard problem. This issue typically shows up when trying to run supervised in an unsupported way with other software interfering with docker (hence why the discussion you linked is primarily ubuntu users). I have never seen this behavior in testing when the only things done on the host are the steps listed in the supervised installer (the only supported way to run supervised).
Have you customized the host machine beyond just running the supervised installer? Any other software installed/running that might be interfering with docker or dependencies? The current list of supported/unsupported isn't an exhaustive list, we don't have the time to test everything that could possibly break supervised as the list is infinite. We just add checks as issues alert us to changes which caused problems.
Or perhaps when was the last time you ran the supervised installer? In a supervised type installation the task of keeping the host up to date is put on you, the user. HA does not update any software on the host in this type of installation, it just stays within containers. It's expected that you will periodically re-run the supervised installer to ensure host dependencies are up to date.
This is a bit depressing. In my case, it involves opening a sh session in my server to run it. I need also to have this solution saved for reference somewhere so I remember what to do in such recurring situation.
The expectation is that users running supervised are linux and docker experts, completely comfortable in the cli. Nearly all solutions proposed for supervised users are going to be cli solutions (starting with the install process itself) because sysdmins are effectively the target user there.
It sounds like you are not particularly comfortable in the CLI since you referred to restarting a docker container via the CLI as a complicated solution. In that case I might suggest using an HAOS type install instead of supervised. Since it sounds like you want an appliance install where everything can be managed in the UI (which is what HAOS is).
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm experiencing the exact same thing. It started acting up (as I try to remember it correctly) when I installed the beta of 2023.7, I believe I started using the beta from b3.
hassio_supervisor = privileged:
mhoogenbosch@homeassistant ~ [10:15:40]
> $ sudo docker inspect --format='{{.HostConfig.Privileged}}' hassio_supervisor
true
System info:
agent_version: 1.5.1
apparmor_version: 3.0.8
boot_timestamp: 1690215768633925
broadcast_llmnr: true
broadcast_mdns: true
chassis: desktop
cpe: ""
deployment: ""
disk_free: 331.6
disk_life_time: null
disk_total: 455.9
disk_used: 101.1
dt_synchronized: true
dt_utc: "2023-07-27T07:16:17.114638+00:00"
features:
- reboot
- shutdown
- services
- network
- hostname
- timedate
- os_agent
- resolved
- journal
- disk
- mount
hostname: homeassistant
kernel: 6.1.0-10-amd64
llmnr_hostname: homeassistant
operating_system: Debian GNU/Linux 12 (bookworm)
startup_time: 35.982921
timezone: Europe/Amsterdam
use_ntp: false
When I search the web, I often find people using Ubuntu which is not supported, or advising on doing a reboot of the host system. I have Debian 12 installed (which has become supported recently) and have tried rebooting multiple times.
Additional info:
> $ sudo ha supervisor info
addons:
- icon: true
name: Samba share
repository: core
slug: core_samba
state: started
update_available: false
version: 10.0.2
version_latest: 10.0.2
- icon: true
name: ESPHome
repository: 5c53de3b
slug: 5c53de3b_esphome
state: started
update_available: false
version: 2023.7.0
version_latest: 2023.7.0
- icon: true
name: PS5 MQTT
repository: df2164f9
slug: df2164f9_ps5_mqtt
state: started
update_available: false
version: 1.3.1
version_latest: 1.3.1
- icon: true
name: Log Viewer
repository: a0d7b954
slug: a0d7b954_logviewer
state: started
update_available: false
version: 0.15.1
version_latest: 0.15.1
- icon: true
name: FTP
repository: a0d7b954
slug: a0d7b954_ftp
state: started
update_available: false
version: 4.7.1
version_latest: 4.7.1
- icon: true
name: OneDrive Backup
repository: de91e161
slug: de91e161_hassio_onedrive_backup
state: started
update_available: false
version: 2.1.2
version_latest: 2.1.2
- icon: true
name: Double Take Proxy
repository: c7657554
slug: c7657554_double-take-proxy
state: started
update_available: false
version: 1.0.0
version_latest: 1.0.0
- icon: true
name: Exadel CompreFace
repository: c7657554
slug: c7657554_compreface
state: started
update_available: false
version: 1.1.0
version_latest: 1.1.0
- icon: true
name: WireGuard
repository: a0d7b954
slug: a0d7b954_wireguard
state: started
update_available: false
version: 0.8.1
version_latest: 0.8.1
- icon: true
name: Zigbee2MQTT Edge
repository: 45df7312
slug: 45df7312_zigbee2mqtt_edge
state: started
update_available: false
version: edge
version_latest: edge
- icon: true
name: Frigate Proxy
repository: ccab4aaf
slug: ccab4aaf_frigate-proxy
state: started
update_available: false
version: "1.3"
version_latest: "1.3"
- icon: true
name: File editor
repository: core
slug: core_configurator
state: started
update_available: false
version: 5.6.0
version_latest: 5.6.0
addons_repositories:
- name: Local add-ons
slug: local
- name: Double Take Hass.io Add-ons
slug: c7657554
- name: 'Home Assistant Add-on: Zigbee2MQTT'
slug: 45df7312
- name: ESPHome
slug: 5c53de3b
- name: Frigate hass.io addons
slug: ccab4aaf
- name: PS5 MQTT Add-on
slug: df2164f9
- name: Home Assistant Google Drive Backup Repository
slug: cebe7a76
- name: Home Assistant Community Add-ons
slug: a0d7b954
- name: Official add-ons
slug: core
- name: Home Assistant Onedrive Backup Repository
slug: de91e161
arch: amd64
auto_update: true
channel: beta
debug: false
debug_block: false
diagnostics: null
healthy: false
ip_address: 172.30.32.2
logging: info
supported: true
timezone: Europe/Amsterdam
update_available: false
version: 2023.07.2
version_latest: 2023.07.2
wait_boot: 5
> $ sudo ha core info
arch: amd64
audio_input: null
audio_output: null
boot: true
image: ghcr.io/home-assistant/qemux86-64-homeassistant
ip_address: 172.30.32.1
machine: qemux86-64
port: 8123
ssl: false
update_available: false
version: 2023.8.0b0
version_latest: 2023.8.0b0
watchdog: true
Mostly everything works, but when reloading automations for example, a timeout occures:
23-07-27 10:02:19 WARNING (MainThread) [supervisor.jobs] 'HomeAssistantCore.update' blocked from execution, system is not healthy - privileged
23-07-27 10:04:11 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/core/state:
23-07-27 10:06:11 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/core/state:
I don't have anything installed besides HA, no portainer or such a thing. It is a HP T540 thin client which sole purpose is to run HA. I installed debian supervised because the CPU wouldn't excied 1.5Ghz on HASSIO, but this was almost more than a year ago.
Also ran the supervised installer a couple of times, which seems to run fine:
> $ sudo dpkg -i homeassistant-supervised.deb
(Reading database ... 272063 files and directories currently installed.)
Preparing to unpack homeassistant-supervised.deb ...
[warn]
[warn] If you want more control over your own system, run
[warn] Home Assistant as a VM or run Home Assistant Core
[warn] via a Docker container.
[warn]
[warn] ModemManager service is enabled. This might cause issue when using serial devices.
Leaving 'diversion of /etc/NetworkManager/NetworkManager.conf to /etc/NetworkManager/NetworkManager.conf.real by homeassistant-supervised'
Leaving 'diversion of /etc/NetworkManager/system-connections/default to /etc/NetworkManager/system-connections/default.real by homeassistant-supervised'
Leaving 'diversion of /etc/docker/daemon.json to /etc/docker/daemon.json.real by homeassistant-supervised'
Leaving 'diversion of /etc/network/interfaces to /etc/network/interfaces.real by homeassistant-supervised'
Unpacking homeassistant-supervised (1.5.0) over (1.5.0) ...
Setting up homeassistant-supervised (1.5.0) ...
[info] Restarting NetworkManager
[info] Restarting docker service
PING checkonline.home-assistant.io (104.26.4.238) 56(84) bytes of data.
64 bytes from 104.26.4.238: icmp_seq=1 ttl=59 time=6.20 ms
--- checkonline.home-assistant.io ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.197/6.197/6.197/0.000 ms
[info] Install supervisor startup scripts
[info] Install AppArmor scripts
[info] Start Home Assistant Supervised
[info] Installing the 'ha' cli
[info] Within a few minutes you will be able to reach Home Assistant at:
[info] http://homeassistant.local:8123 or using the IP address of your
[info] machine: http://192.168.21.92:8123
Right after, it again is not healthy - privileged
Besides the automation/script reload issue, which I can't figure out, everything runs just fine. All automations, integrations, addons, everything works as expected.
I have the same problem on a Debian 12 machine. After updating the supervisor the installation is unhealthy. Only a reboot of the host machine resolves the problem.
I solved my reloading issue. Was a custom integration called watchman, after removing this it is okay again. The supervisor stays unhealthy however
After a reboot it shows healty btw, after removing watchman, by any chance you are running that integration too?
After removing the watchman integration, my system stays healthy. On my behave, this thread can be closed.
I have the same issue with unhealthy supervisor as not privileged...
Debian 12, reproduced after update supervisor to 2023.08.3.
To fix this issue I have to restart the host.
Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 a arch64
Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm
This happens to me as well. I don't have nay third party software running on my server, but I do have HACS installed along with integrations installed through HACS. Rebooting the supervisor makes the warning disappear during weeks. If it was a persistent issue, should the message not appear way sooner?
thanks
Attached is my supervisor log file from the linked #4529 bug. supervisor.log
According to the UI it occurred around 9AM on the 14th and there is one matching exception at 09:41:
Sep 14 09:41:27 nuc hassio_supervisor[1369]: 23-09-14 09:41:27 ERROR (MainThread) [asyncio] Task exception was never retrieved Sep 14 09:41:27 nuc hassio_supervisor[1369]: future: <Task finished name='Task-3615' coro=<Addon.watchdog_container() done, defined at /usr/src/supervisor/supervisor/addons/addon.py:1069> exception=AddonsJobError('Rate limit exceeded, more then 10 calls in 0:30:00')> Sep 14 09:41:27 nuc hassio_supervisor[1369]: Traceback (most recent call last): Sep 14 09:41:27 nuc hassio_supervisor[1369]: File "/usr/src/supervisor/supervisor/addons/addon.py", line 1083, in watchdog_container Sep 14 09:41:27 nuc hassio_supervisor[1369]: await self._restart_after_problem(event.state) Sep 14 09:41:27 nuc hassio_supervisor[1369]: File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 255, in wrapper Sep 14 09:41:27 nuc hassio_supervisor[1369]: raise on_condition( Sep 14 09:41:27 nuc hassio_supervisor[1369]: supervisor.exceptions.AddonsJobError: Rate limit exceeded, more then 10 calls in 0:30:00
On Debian Bookworm, configured according to the instructions with no other modifications: I get this lapse back into "unhealthy" whenever I get a notification for a new update to Hone Assistant Core. Restarting fixes the problem. But again, it only happens when I get a notification for an update to Home Assistant Core.
I also chatted with someone who has this problem too, and they think it's whenever unattended-upgrades gets kicked off. Not sure if they are related.
On Debian Bookworm, configured according to the instructions with no other modifications: I get this lapse back into "unhealthy" whenever I get a notification for a new update to Hone Assistant Core. Restarting fixes the problem. But again, it only happens when I get a notification for an update to Home Assistant Core.
I also chatted with someone who has this problem too, and they think it's whenever
unattended-upgradesgets kicked off. Not sure if they are related.
This also happens to me when a new update is available to Home Assistant Core. My system info is attached. Running HA Supervised on Debian 12 with no other Docker containers or other services. ha_sys_info.txt
I have been looking into this issue and am not entirely sure why this is happening, whenever the supervisor container is removed and recreated the supervisor spits out this error:
INFO (MainThread) [supervisor.jobs] 'ResolutionFixup.run_autofix' blocked from execution, system is not healthy - privileged
I have noticed if the supervisor container is restarted again or the host is restarted it will clear itself up. Thus why you might get this error after a supervisor update and a reboot seems to fix it. The container that is being created is privileged just like on HAOS. Still working to find a solution if anyone has any insight as to what might be going on let me know
I'm having the same problem on Debian Bookworm which should be supported:
It happens with some weeks inbetween. Tracing the source code, all points to checking the container attributes. Both docker inspect and python container attributes list the container as privileged. Where else can I trace the "non-privilege"?
# docker inspect hassio_supervisor|grep Priv
"Privileged": true,
# docker exec -ti hassio_supervisor python
Python 3.11.5 (main, Sep 28 2023, 17:20:50) [GCC 11.2.1 20220219] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import docker
>>> client = docker.from_env()
>>> container = client.containers.get('hassio_supervisor')
>>> container.attrs['HostConfig']['Privileged']
True
>>>
Doing a docker restart hassio_supervisor solves the problem temporarily.
Same issue here - it's so annoying. Every time HA gets updated this occurs.
Workaround: Restarting the host OS solves the problem until next supervisor update. This is obviously a problem with HA and not the OS.
System: Running HA supervised in docker on a Intel NUC with latest Debian OS. According to specs this is supported.
With the frequent updates of HA, symptom treating this with manual restart of the host OS isn't satifactory. Please get this fixed.
I have been experiencing the same problem on two separate (supervised but supported) instances for quite some time now. The common pattern makes it pretty obvious how and where it all goes pearshaped - and hopefully for the devs what to do about it. After at least half a year of suffering from this bug, a solution would be welcomed by us 'supervised' users - of which there are many ...
Same. The recent supervisor update prompted it. This only started happening after I updated to bookworm and used the latest HA pkg.
My fix is quite simple, although it goes against every instinct. Click "ignore". After a few minutes, I can go about updating add-ons, etc, like nothing is wrong. (Because nothing is?)
Having the same problem, on Bookworm. Worked great until I did the latest update. But now it says that this error happened "2 weeks ago" even tho it was never ignored. When it happened two weeks ago, I updated everything on the OS, re-run the ha-supervised installation and it went away. Until now.
Also, quick look in docker says: "Privileged: true"
Also, also, no need for host restart. "sudo service docker restart" and the error is gone, all healthy. -.-
+1, just got the same error.... Issuing a reboot of the host to correct the issue. Seems odd a reboot is all it needs.
Debian 12 (Bookworm) [recently upgraded from Debian 11 (Bullseye)]
Stock install running on a mid-2011 MacMini (for over a year now)
Odd the OS release isn't reported in the about section..
fireheadman@shield:~$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ghcr.io/home-assistant/amd64-hassio-supervisor 2023.11.0 188fa2dc2ce7 2 days ago 361MB
ghcr.io/home-assistant/amd64-hassio-supervisor latest 188fa2dc2ce7 2 days ago 361MB
ghcr.io/home-assistant/qemux86-64-homeassistant 2023.11.1 054d9190ed12 4 days ago 1.9GB
zigbee2mqtt/zigbee2mqtt-amd64 1.33.2-1 26df3e4a4e7f 6 days ago 174MB
ghcr.io/home-assistant/amd64-hassio-audio 2023.10.0 10641e68da2c 7 days ago 120MB
ghcr.io/hassio-addons/zwave-js-ui/amd64 3.0.1 28c57353ff96 8 days ago 367MB
ghcr.io/hassio-addons/bitwarden/amd64 0.20.1 842df2c52d95 3 weeks ago 251MB
ghcr.io/hassio-addons/tasmoadmin/amd64 0.25.1 557cf6f9f34f 3 weeks ago 83.7MB
ghcr.io/hassio-addons/phpmyadmin/amd64 0.8.9 37e81618709c 3 weeks ago 194MB
ghcr.io/home-assistant/amd64-hassio-cli 2023.10.0 ac2d9773e777 4 weeks ago 92.4MB
homeassistant/amd64-addon-mosquitto 6.3.1 973c50be2983 2 months ago 209MB
ghcr.io/home-assistant/amd64-hassio-dns 2023.06.2 6f219c25373a 4 months ago 104MB
ghcr.io/home-assistant/amd64-hassio-multicast 2023.06.2 74a5ecf0d658 4 months ago 87.6MB
ghcr.io/home-assistant/amd64-hassio-observer 2023.06.0 5a1f2299c4fa 4 months ago 7.76MB
sabeechen/hassio-google-drive-backup-amd64 0.111.1 8a19534d3c0f 4 months ago 307MB
homeassistant/amd64-addon-mariadb 2.6.1 a3d2efe2dafc 6 months ago 309MB
ghcr.io/hassio-addons/nginxproxymanager/amd64 0.12.3 3ac2a4f880d2 11 months ago 249MB
danmed/tasmobackupv1 1.05.00 540fe3fd8fcf 13 months ago 154MB
fireheadman@shield:~$ sudo docker info
Client: Docker Engine - Community
Version: 24.0.7
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.11.2
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.21.0
Path: /usr/libexec/docker/cli-plugins/docker-compose
scan: Docker Scan (Docker Inc.)
Version: v0.23.0
Path: /usr/libexec/docker/cli-plugins/docker-scan
Server:
Containers: 16
Running: 16
Paused: 0
Stopped: 0
Images: 17
Server Version: 24.0.7
Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: journald
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 61f9fd88f79f081d64d6fa3bb1a0dc71ec870523
runc version: v1.1.9-0-gccaecfc
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
Kernel Version: 6.1.0-13-amd64
Operating System: Debian GNU/Linux 12 (bookworm)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.53GiB
Name: shield
ID: ebaeacf4-28e6-4a48-986b-432f615665ed
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
I'm experiencing the same issue. It started for me back in early October on Debian 11. After a complete reinstall on Debian 12, the error message reappeared today. Restarting 'hassio_supervisor' resolves the problem temporarily.
Hopefully this is not piling on but...
I'm experiencing the same issue. Within the last 5 days I installed a fresh copy of Debian 12 on an RP4 and finished the supervised installation. Twice now it's simply said it's unhealthy, a reboot fixes everything.
Had it happen again.... but slightly different. This time I noticed there was an update for supervisor. I thought maybe this was the fix. So I clicked to update it, then I popped up the issue again.
nevertheless, I had to reboot the host again to clear the error and this also seemed to release the alert/notice for the supervisor update, so maybe a fix was applied??? (time will tell).
After the reboot, I was able to apply the latest HA update without any issue.
I am having the same issue since last week. Tried everything, reinstall convience script, os agent, supervisor update/reinstall. Sometimes a reboot solves the issue.
I am running HA supervised on Debian 12 on a Dell Optiplex 3060 micro. My Home Assistant installation has been running fine for over 3 year on this hardware. (I updated from Debian 11 to Debian 12 about 2 months ago, and has been running fine since then)
Versions:
It is not the answer for the mistery of this issue, but solves the problem quickly without restarting the whole host. (At least it does solve it for me.)
-
Going to Terminal
-
Typing
ha supervisor restart
Just to add my two cents, I have the same issues and it seems to occur around a new version notification. However, this time I have a new error (which would explain why running the installer script fixes things perhaps):
System is currently unhealthy because an attempt to update Supervisor to the latest version has failed. Use the link to learn more and how to fix this.
Perhaps it's a chicken and egg problem? Update needs the new supervisor to run, but the new supervisor cannot be updated because it needs the new update first
seeing the same thing. fresh install using debian 12. host restart clears the issue, but unknown if it will return
Update 20231207: upgraded to 2023.12.0 without the warning for now Update 20231220: the warning came back after I did
apt upgrade.
Same here, getting this in the supervisor log
[supervisor.jobs] 'ResolutionFixup.run_autofix' blocked from execution, system is not healthy - privileged
Rebooting will fix it for like two weeks
