It’s happened to me several times:
I try to stop a running container and it fails to stop and it can’t be force-stopped or killed either.
When this happens, Container Station itself also cannot be stopped, and finally, trying to restart the NAS fails. It is totally unacceptable that a single runaway container can cause the whole NAS to become unresponsive. The whole purpose of container technology is to isolate and protect the NAS OS from malfunctioning containers. In case of QNAP, this seems to be a known issue. Their container engine implementation isn’t robust enough.
Just for the records; Of course I tried all possible ways to stop, cancel, reboot and kill from CLI, but to no avail. The only and final solution was hard reset.
Never had this happen to me …what container did this happen on?
Home Assistant v2025.5.1
Im on 2025.5.3 with no issue with crashes
Can you access in ssh?
if yes docker “docker ps” then “stop <container_name>”
dump the logs here
“cat /var/log/log_sys.log” and "cat /var/log/docker.log " and or “docker logs <container_name>”
Can’t help without logs.
As I already said; I tried all possible (and impossible) CLI commands, but to no avail.
Did you open a ticket so QNAP can take a look at it ?
Your posts sounds like this container station issue is widely discussed, but that is the first time I have heard of it (Unless this is not publicly discussed on the usual reddit/community/etc places)
I had to har reset the NAS to get back up.
It was ChatGPT that informed me that this was a known problem with CS. And that matches well with my own experience. This is not the first time it has happened to me.
Not doubting you have the issue, but ChatGPT is a very bad source as it’s known to make up facts on the spot (hallucination)… As long as I don’t see these issues anywhere else, where would that info for ChatGPT come from ? (and these LLMs are often many many months behind when it comes to up to date info)
You never said if you opened a ticket or not.
Hi,
We’ve noticed this issue and would like to request more detailed environmental information to help us investigate. Could you please provide details such as your NAS model, firmware version, any installed apps, or activated services?
Thank you.
This has happened several times. Last time it happened, I took the time to analyse the log more deeply. My attention focused on this log entry:
homeass-1 | File "/usr/src/homeassistant/homeassistant/core.py", line 1731, in _async_remove_listener
homeass-1 | self._listeners[event_type].remove(filterable_job)
homeass-1 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
homeass-1 | ValueError: list.remove(x): x not in list
homeass-1 | 2025-06-11 14:50:20.239 WARNING (Thread-8 (_do_shutdown)) [homeassistant.util.executor] Thread[SyncWorker_1] is still running at shutdown: File "/usr/local/lib/python3.13/threading.py", line 1012, in _bootstrap
homeass-1 | self._bootstrap_inner()
homeass-1 | File "/usr/local/lib/python3.13/threading.py", line 1041, in _bootstrap_inner
homeass-1 | self.run()
homeass-1 | File "/usr/local/lib/python3.13/threading.py", line 992, in run
homeass-1 | self._target(*self._args, **self._kwargs)
homeass-1 | File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 93, in _worker
homeass-1 | work_item.run()
homeass-1 | File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59, in run
homeass-1 | result = self.fn(*self.args, **self.kwargs)
homeass-1 | File "/usr/src/homeassistant/homeassistant/components/qnap/coordinator.py", line 82, in _sync_update
homeass-1 | "volumes": self._api.get_volumes(),
homeass-1 | File "/usr/local/lib/python3.13/site-packages/qnapstats/qnap_stats.py", line 142, in get_volumes
homeass-1 | resp = self._get_url(
homeass-1 | File "/usr/local/lib/python3.13/site-packages/qnapstats/qnap_stats.py", line 79, in _get_url
homeass-1 | self._get_url(url, False, **kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/qnapstats/qnap_stats.py", line 76, in _get_url
homeass-1 | result = self._execute_get_url(url, **kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/qnapstats/qnap_stats.py", line 92, in _execute_get_url
homeass-1 | resp = self._session.get(url, timeout=self._timeout, verify=self._verify_ssl)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/requests/sessions.py", line 602, in get
homeass-1 | return self.request("GET", url, **kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/requests/sessions.py", line 589, in request
homeass-1 | resp = self.send(prep, **send_kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/requests/sessions.py", line 703, in send
homeass-1 | r = adapter.send(request, **kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/requests/adapters.py", line 667, in send
homeass-1 | resp = conn.urlopen(
homeass-1 | File "/usr/local/lib/python3.13/site-packages/urllib3/connectionpool.py", line 716, in urlopen
homeass-1 | httplib_response = self._make_request(
homeass-1 | File "/usr/local/lib/python3.13/site-packages/urllib3/connectionpool.py", line 463, in _make_request
homeass-1 | httplib_response = conn.getresponse()
homeass-1 | File "/usr/local/lib/python3.13/http/client.py", line 1430, in getresponse
homeass-1 | response.begin()
homeass-1 | File "/usr/local/lib/python3.13/http/client.py", line 331, in begin
homeass-1 | version, status, reason = self._read_status()
homeass-1 | File "/usr/local/lib/python3.13/http/client.py", line 292, in _read_status
homeass-1 | line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
homeass-1 | File "/usr/local/lib/python3.13/socket.py", line 719, in readinto
homeass-1 | return self._sock.recv_into(b)
homeass-1 | 2025-06-11 14:50:21.220 WARNING (Thread-8 (_do_shutdown)) [homeassistant.util.executor] Thread[SyncWorker_1] is still running at shutdown: File "/usr/local/lib/python3.13/threading.py", line 1012, in _bootstrap
homeass-1 | self._bootstrap_inner()
homeass-1 | File "/usr/local/lib/python3.13/threading.py", line 1041, in _bootstrap_inner
homeass-1 | self.run()
homeass-1 | File "/usr/local/lib/python3.13/threading.py", line 992, in run
homeass-1 | self._target(*self._args, **self._kwargs)
homeass-1 | File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 93, in _worker
homeass-1 | work_item.run()
homeass-1 | File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59, in run
homeass-1 | result = self.fn(*self.args, **self.kwargs)
homeass-1 | File "/usr/src/homeassistant/homeassistant/components/qnap/coordinator.py", line 82, in _sync_update
homeass-1 | "volumes": self._api.get_volumes(),
homeass-1 | File "/usr/local/lib/python3.13/site-packages/qnapstats/qnap_stats.py", line 142, in get_volumes
homeass-1 | resp = self._get_url(
homeass-1 | File "/usr/local/lib/python3.13/site-packages/qnapstats/qnap_stats.py", line 79, in _get_url
homeass-1 | self._get_url(url, False, **kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/qnapstats/qnap_stats.py", line 76, in _get_url
homeass-1 | result = self._execute_get_url(url, **kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/qnapstats/qnap_stats.py", line 92, in _execute_get_url
homeass-1 | resp = self._session.get(url, timeout=self._timeout, verify=self._verify_ssl)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/requests/sessions.py", line 602, in get
homeass-1 | return self.request("GET", url, **kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/requests/sessions.py", line 589, in request
homeass-1 | resp = self.send(prep, **send_kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/requests/sessions.py", line 703, in send
homeass-1 | r = adapter.send(request, **kwargs)
homeass-1 | File "/usr/local/lib/python3.13/site-packages/requests/adapters.py", line 667, in send
homeass-1 | resp = conn.urlopen(
homeass-1 | File "/usr/local/lib/python3.13/site-packages/urllib3/connectionpool.py", line 716, in urlopen
homeass-1 | httplib_response = self._make_request(
homeass-1 | File "/usr/local/lib/python3.13/site-packages/urllib3/connectionpool.py", line 463, in _make_request
homeass-1 | httplib_response = conn.getresponse()
homeass-1 | File "/usr/local/lib/python3.13/http/client.py", line 1430, in getresponse
homeass-1 | response.begin()
homeass-1 | File "/usr/local/lib/python3.13/http/client.py", line 331, in begin
homeass-1 | version, status, reason = self._read_status()
homeass-1 | File "/usr/local/lib/python3.13/http/client.py", line 292, in _read_status
homeass-1 | line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
homeass-1 | File "/usr/local/lib/python3.13/socket.py", line 719, in readinto
homeass-1 | return self._sock.recv_into(b)
homeass-1 | 2025-06-11 14:50:22.019 ERROR (MainThread) [homeassistant.components.systemmonitor.coordinator] Unexpected error fetching System Monitor update coordinator data
homeass-1 | Traceback (most recent call last):
homeass-1 | File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 380, in _async_refresh
homeass-1 | self.data = await self._async_update_data()
homeass-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
homeass-1 | File "/usr/src/homeassistant/homeassistant/components/systemmonitor/coordinator.py", line 135, in _async_update_data
homeass-1 | _data = await self.hass.async_add_executor_job(self.update_data)
homeass-1 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
homeass-1 | File "/usr/src/homeassistant/homeassistant/core.py", line 878, in async_add_executor_job
homeass-1 | task = self.loop.run_in_executor(None, target, *args)
homeass-1 | File "/usr/local/lib/python3.13/asyncio/base_events.py", line 888, in run_in_executor
homeass-1 | self._check_default_executor()
homeass-1 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
homeass-1 | File "/usr/local/lib/python3.13/asyncio/base_events.py", line 554, in _check_default_executor
homeass-1 | raise RuntimeError('Executor shutdown has been called')
homeass-1 | RuntimeError: Executor shutdown has been called
This error occurs in the Home Assistant core (core.py, line 1731) during the shutdown process. It happens when the system tries to remove an event listener from a list, but the listener isn’t found. This could be due to a bug or a race condition where the listener was already removed or never properly registered.
I suspect this is a bug in the QNAP Integration; QNAP - Home Assistant
Threads Still Running at Shutdown
The log shows warnings about threads (e.g., SyncWorker_1) still running when Home Assistant attempts to shut down. These threads are stuck in API calls to the QNAP NAS, specifically in the get_volumes() function (qnap_stats.py, line 142). The stack trace reveals that these threads are waiting for a response from the QNAP API over the network, which doesn’t arrive before the shutdown process begins.
Executor Shutdown Error
The final error occurs in the system monitor coordinator (systemmonitor/coordinator.py, line 135), where Home Assistant tries to fetch data after the executor (which manages background tasks) has already been shut down. This is a downstream effect of the incomplete shutdown caused by the above issues.
This error confirms that the shutdown sequence is disrupted, leaving some components in an inconsistent state.
Possible Causes
- QNAP API Issues: The threads are stuck waiting for the QNAP API (get_volumes()), possibly due to network delays, timeouts, or an unresponsive API.
- Home Assistant Bug: The ValueError suggests a potential issue in how Home Assistant manages listeners during shutdown.
- Shutdown Sequence: The executor is shutting down prematurely, likely because hanging threads delay the process, leading to resource cleanup failures.
However, the error message:
ValueError: list.remove(x): x not in list
Thread[SyncWorker_1] is still running at shutdown
RuntimeError: Executor shutdown has been called
… indicates that Home Assistant is launching background threads (via the qnapstats-based QNAP integration) and, when it gets a SIGTERM from Container Station, those threads never cleanly exit. Because the default Docker “stop timeout” is only 10 seconds, Container Station gives up waiting for HA’s Python process to die and the container never goes down gracefully. (This same symptom has been reported on QNAP’s Community forums before, but QNAP staff hasn’t picked it up)
The QNAP integration in Home Assistant uses the qnapstats
library, which spawns background threads to collect data from my QNAP NAS.
When Container Station sends a SIGTERM
signal to stop the Home Assistant container, these threads do not terminate properly, preventing the Python process from shutting down gracefully.
Docker’s default stop timeout is only 10 seconds. If the container doesn’t stop within this window, Container Station forcibly terminates it, leading to the errors in the log.
Solution?
I am trying to solve this by adding stop_grace_period: 60s
to the docker compose file for my Home Assistant container.
It remains to be seen if this has any effects.
Rgds