Es ist mir schon mehrere Male passiert:
Ich versuche, einen laufenden Container zu stoppen, aber er lässt sich nicht stoppen und kann auch nicht zwangsweise beendet oder gekillt werden.
Wenn das passiert, lässt sich auch Container Station selbst nicht mehr stoppen, und schließlich schlägt auch der Versuch fehl, das NAS neu zu starten. Es ist völlig inakzeptabel, dass ein einzelner außer Kontrolle geratener Container das gesamte NAS lahmlegen kann. Der ganze Zweck der Container-Technologie besteht darin, das NAS-Betriebssystem vor fehlerhaften Containern zu isolieren und zu schützen. Im Fall von QNAP scheint dies ein bekanntes Problem zu sein. Ihre Container-Engine-Implementierung ist nicht robust genug.
Nur der Vollständigkeit halber: Natürlich habe ich alle möglichen Wege ausprobiert, um über die CLI zu stoppen, abzubrechen, neu zu starten und zu killen, aber ohne Erfolg. Die einzige und endgültige Lösung war ein Hard-Reset.
Das ist mir noch nie passiert … bei welchem Container ist das passiert?
Home Assistant v2025.5.1
Ich bin auf Version 2025.5.3 und habe keine Probleme mit Abstürzen.
Kannst du per SSH darauf zugreifen?
Falls ja, führe bei Docker „docker ps“ aus und dann „stop <container_name>“.
Gib die Logs hier aus
„cat /var/log/log_sys.log“ und „cat /var/log/docker.log“ und/oder „docker logs <container_name>“
Ohne Logs kann ich nicht helfen.
Wie ich bereits sagte: Ich habe alle möglichen (und unmöglichen) CLI-Befehle ausprobiert, aber ohne Erfolg.
Hast du ein Ticket eröffnet, damit QNAP sich das anschauen kann?
Deine Beiträge klingen so, als würde dieses Container Station-Problem weitläufig diskutiert werden, aber das ist das erste Mal, dass ich davon höre (es sei denn, es wird nicht öffentlich in den üblichen Reddit-/Community-/etc.-Plattformen besprochen).
Ich musste das NAS hart zurücksetzen, um es wieder zum Laufen zu bringen.
ChatGPT hat mich darüber informiert, dass dies ein bekanntes Problem mit CS ist. Und das passt gut zu meinen eigenen Erfahrungen. Es ist nicht das erste Mal, dass mir das passiert ist.
Ich bezweifle nicht, dass du das Problem hast, aber ChatGPT ist eine sehr schlechte Quelle, da es dafür bekannt ist, Fakten einfach zu erfinden (Halluzination)… Solange ich diese Probleme sonst nirgends sehe, woher sollte ChatGPT diese Informationen haben? (Und diese LLMs sind oft viele, viele Monate hinterher, wenn es um aktuelle Informationen geht.)
Du hast nie gesagt, ob du ein Ticket eröffnet hast oder nicht.
Hallo,
wir haben dieses Problem festgestellt und möchten Sie bitten, uns detailliertere Umgebungsinformationen zur Verfügung zu stellen, um die Untersuchung zu erleichtern. Könnten Sie bitte Angaben wie Ihr NAS-Modell, die Firmware-Version, installierte Apps oder aktivierte Dienste machen?
Vielen Dank.
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
Ich hatte gerade das gleiche Problem. Nachdem ich versucht habe, eine Anwendung in Container Station zu starten, wurde die NAS-Weboberfläche nicht mehr reagibel. Als ich versuchte, mich erneut einzuloggen, blieb alles auf dem blauen „Loading“-Bildschirm hängen. Ich musste mich per SSH einloggen, alle Apache-Prozesse beenden und dann den thttpd-Dienst neu starten.
Update: Offenbar ist das passiert, weil ich versehentlich einen Container-Volume-Mount-Pfad verwendet habe, der sich nicht auf einem Share befindet, was zu einem vollen RAM-Disk geführt hat (überprüfe dies mit dem Befehl „df /“ per SSH).