app.state is set to ERROR instead of STOPPED when manually stopping an add-on that exits with non-zero exit code

[GuiPoM]

Describe the issue you are experiencing

When an add-on is stopped manually via the HA UI, the Supervisor REST API (GET /addons/<slug>/info) returns state: "error" instead of state: "stopped".

Root cause: in supervisor/apps/app.py, container_state_changed() sets AppState.ERROR for ContainerState.FAILED without checking _manual_stop:

elif event.state == ContainerState.FAILED:
    self.state = AppState.ERROR   # _manual_stop is NOT checked here

When docker stop sends SIGTERM and the container exits with code 143 (SIGTERM not handled gracefully by the add-on), Docker records ContainerState.FAILED, which always results in AppState.ERROR regardless of whether the stop was intentional.

_manual_stop is correctly set to True in stop() and IS checked in watchdog_container() to skip unwanted restarts — but container_state_changed() ignores it entirely.

Proposed fix in container_state_changed():

elif event.state == ContainerState.FAILED:
    self.state = AppState.STOPPED if self._manual_stop else AppState.ERROR

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Other (e.g., Raspbian/Raspberry Pi OS/Fedora)

Steps to reproduce the issue

1. Start any add-on (e.g. File editor / core_configurator)
2. Stop it manually via Settings → Add-ons → Stop
3. Query from SSH terminal:
   curl -sSL -H "Authorization: Bearer $SUPERVISOR_TOKEN"
   http://supervisor/addons/core_configurator/info
   | python3 -m json.tool | grep '"state"'
4. Observe: "state": "error" instead of "state": "stopped"

Anything in the Supervisor logs that might be useful for us?

2026-05-13 21:49:11.040 INFO (MainThread) [supervisor.docker.manager] Stopping addon_core_configurator application
2026-05-13 21:49:14.241 INFO (MainThread) [supervisor.docker.manager] Cleaning addon_core_configurator application
No errors logged — the state transition to ERROR happens silently in memory via container_state_changed().

System information

System Information

version	core-2026.5.1
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
container_arch	amd64
user	root
virtualenv	false
python_version	3.14.2
os_name	Linux
os_version	6.12.85-haos
arch	x86_64
timezone	Europe/Paris
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	5000
Installed Version	2.0.5
Stage	running
Available Repositories	3009
Downloaded Repositories	19

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	Home Assistant OS 17.3
update_channel	stable
supervisor_version	supervisor-2026.05.0
agent_version	1.8.1
docker_version	29.3.1
disk_total	56.0 GB
disk_used	40.2 GB
nameservers	fe80::229a:7dff:fe28:93d0, 192.168.1.1, 2a01:cb05:7e1:500:229a:7dff:fe28:93d0, 192.168.1.25
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	generic-x86-64
supervisor_api	ok
version_api	ok
installed_addons	Matter Server (8.4.0), Piper (2.2.2), Samba share (12.6.1), Nginx Proxy Manager (2.1.0), Speech-to-Phrase (1.4.3), Advanced SSH & Web Terminal (23.0.9), OpenThread Border Router (2.16.8), vosk (1.6.1), Gazpar2HAWS (0.5.0), Zigbee2MQTT (2.10.1-1), AdGuard Home (6.1.3), File editor (6.0.0), Network UPS Tools (0.18.0), Mosquitto broker (7.1.0), Z-Wave JS UI (7.3.0), WG Easy 15+ (15.2.2)

Dashboards

dashboards	5
resources	2
views	23
mode	storage

Network Configuration

adapters	lo (disabled), enp1s0 (enabled, default, auto), hassio (disabled), docker0 (disabled), veth52dab75 (disabled), vethd8a6a64 (disabled), vethfa30f57 (disabled), veth42be94f (disabled), veth3b7bbdd (disabled), veth1fa731b (disabled), vethb6ea517 (disabled), wpan0 (disabled), vethf8f4f60 (disabled), vethb3fad12 (disabled), vethbae16bc (disabled), veth7f3c437 (disabled), veth0f9f0fa (disabled), vethd3f3d7a (disabled), vetha7febbd (disabled), veth4f15738 (disabled), veth33c53fc (disabled)
ipv4_addresses	lo (127.0.0.1/8), enp1s0 (192.168.1.25/24), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), veth52dab75 (), vethd8a6a64 (), vethfa30f57 (), veth42be94f (), veth3b7bbdd (), veth1fa731b (), vethb6ea517 (), wpan0 (), vethf8f4f60 (), vethb3fad12 (), vethbae16bc (), veth7f3c437 (), veth0f9f0fa (), vethd3f3d7a (), vetha7febbd (), veth4f15738 (), veth33c53fc ()
ipv6_addresses	lo (::1/128), enp1s0 (2a01:cb05:7e1:500:5bb7:5c2e:c4e9:60a3/64, fd87:3b15:78bc:a1f9:c9d1:4c4a:f525:c59e/64, fe80::f701:8192:4ceb:7abf/64), hassio (fd0c:ac1e:2100::1/48, fe80::60f4:18ff:fea9:6ba6/64), docker0 (fe80::411:e8ff:fe03:a0ce/64), veth52dab75 (fe80::1cc4:d0ff:fed5:f119/64), vethd8a6a64 (fe80::8c51:feff:fee4:3d31/64), vethfa30f57 (fe80::3058:4dff:fe74:7b13/64), veth42be94f (fe80::30e1:38ff:fe8b:51d4/64), veth3b7bbdd (fe80::e47d:37ff:fed6:b3f7/64), veth1fa731b (fe80::a461:c8ff:fe09:e9f4/64), vethb6ea517 (fe80::7810:7eff:fe6e:a15d/64), wpan0 (fd10:7e18:2341:7fc0:0:ff:fe00:fc11/64, fdd8:c6e1:96bb:1:2e:4c1a:2b36:8d8e/64, fd10:7e18:2341:7fc0:0:ff:fe00:fc10/64, fd10:7e18:2341:7fc0:0:ff:fe00:fc38/64, fd10:7e18:2341:7fc0:0:ff:fe00:8400/64, fd10:7e18:2341:7fc0:ec24:5d7c:83b6:c848/64, fe80::28bf:6438:f68b:a3b2/64), vethf8f4f60 (fe80::a8ee:66ff:fedc:c951/64), vethb3fad12 (fe80::24dd:38ff:fec1:ad43/64), vethbae16bc (fe80::4492:3cff:fe41:727f/64), veth7f3c437 (fe80::a4ae:96ff:fe95:8113/64), veth0f9f0fa (fe80::5c93:a0ff:fe6a:24db/64), vethd3f3d7a (fe80::f0b3:deff:febf:49be/64), vetha7febbd (fe80::44e:acff:fe1d:9292/64), veth4f15738 (fe80::f055:84ff:feaf:a69e/64), veth33c53fc (fe80::88b2:99ff:fe83:1681/64)
announce_addresses	192.168.1.25, 2a01:cb05:7e1:500:5bb7:5c2e:c4e9:60a3, fd87:3b15:78bc:a1f9:c9d1:4c4a:f525:c59e, fe80::f701:8192:4ceb:7abf

Recorder

oldest_recorder_run	2 mai 2026 à 9:34 PM
current_recorder_run	13 mai 2026 à 9:46 PM
estimated_db_size	622.20 MiB
database_engine	sqlite
database_version	3.49.2

Supervisor diagnostics

config_entry-hassio-44b94439c287847721776982e19a040f.json

Additional information

No response

[agners]

One could argue that a container should gracefully handles SIGTERM and exits with exit 0.

In fact, if you use --restart on-failure in Docker, and exit code is non-zero, it considers it as failure and restarts the container. So Docker itself sees non-zero exit code as a failure.

Proposed fix in container_state_changed():

elif event.state == ContainerState.FAILED:
self.state = AppState.STOPPED if self._manual_stop else AppState.ERROR

With that in mind, I'd say Container state failed is correct, if a manual stop is not handled gracefully. We should probably write a warning in the logs. Apps which have that behavior should be fixed.

[GuiPoM]

Hi @agners,

I totally understand your point, and you are technically right. Containers should handle SIGTERM gracefully and exit with 0.

That said, I am working on a monitoring integration for Home Assistant that aims to surface problems across apps, integrations and devices in a unified way. In practice, we have found that quite a few official add-ons do not respect this behavior, which makes it hard to reliably distinguish a real crash from an intentional stop.

Getting all third-party add-ons to fix this seems like a long road. Any chance a warning in the logs could be accompanied by a way to distinguish the two cases programmatically?

[agners]

Getting all third-party add-ons to fix this seems like a long road. Any chance a warning in the logs could be accompanied by a way to distinguish the two cases programmatically?

Yeah so I think we should add a warning on non-zero exits, or maybe even distinguish the two for the message: Warning on SIGTERM, error on all other non-zero exit codes.

From what I understand you'd want SIGTERM to be considered non-failure? I guess we can deploy that as a temporary measure until apps got fixed. But maybe we can also just fix the most popular ones and it will be acceptable for your monitoring integration? 🤔

we have found that quite a few official add-ons do not respect this behavior

Can you name them so we can tackle those?

[GuiPoM]

Hi,

Thanks for looking into this. Regarding the add-ons, the two official ones I have received feedback on from the community are configurator (File Editor) and ssh (Advanced SSH & Web Terminal). I am still waiting for more reports from users but those are the ones confirmed so far. For reference, vosk (third-party) also exhibits the same behavior.

The distinction between SIGTERM and other non-zero exit codes sounds like a pragmatic approach and would already help a lot internally. That said, if the distinction is only reflected in the logs and not exposed through the API, it remains hard to observe programmatically. For a monitoring integration like mine, having _manual_stop or an equivalent field surfaced in addon_info() would make it possible to reliably ignore intentional stops vs real failures.