Ini sudah beberapa kali terjadi pada saya:
Saya mencoba menghentikan sebuah container yang sedang berjalan dan gagal dihentikan, bahkan tidak bisa dipaksa berhenti atau dibunuh sekalipun.
Ketika ini terjadi, Container Station sendiri juga tidak bisa dihentikan, dan akhirnya, mencoba me-restart NAS pun gagal. Sangat tidak dapat diterima bahwa satu container yang bermasalah dapat menyebabkan seluruh NAS menjadi tidak responsif. Tujuan utama dari teknologi container adalah untuk mengisolasi dan melindungi OS NAS dari container yang bermasalah. Dalam kasus QNAP, ini tampaknya merupakan masalah yang sudah diketahui. Implementasi mesin container mereka belum cukup tangguh.
Sebagai catatan; Tentu saja saya sudah mencoba semua cara untuk menghentikan, membatalkan, me-reboot, dan membunuh dari CLI, tapi tidak berhasil. Satu-satunya solusi terakhir adalah hard reset.
Tidak pernah mengalami hal seperti ini… di kontainer yang mana ini terjadi?
Home Assistant v2025.5.1
Saya menggunakan 2025.5.3 tanpa masalah crash.
Bisakah Anda mengakses melalui SSH?
Jika ya, jalankan docker “docker ps” lalu “stop <container_name>”
Dump log di sini
“cat /var/log/log_sys.log” dan “cat /var/log/docker.log” atau “docker logs <container_name>”
Tidak bisa membantu tanpa log.
Seperti yang sudah saya katakan; saya sudah mencoba semua perintah CLI yang mungkin (dan bahkan yang tidak mungkin), tetapi tetap tidak berhasil.
Apakah Anda sudah membuka tiket agar QNAP dapat memeriksanya?
Postingan Anda terdengar seolah-olah masalah container station ini sudah banyak dibahas, tetapi ini adalah pertama kalinya saya mendengarnya (Kecuali jika ini memang tidak dibahas secara publik di tempat biasa seperti reddit/komunitas/dll).
Saya harus melakukan hard reset pada NAS agar bisa kembali normal.
ChatGPT yang memberi tahu saya bahwa ini adalah masalah yang sudah diketahui dengan CS. Dan itu sangat sesuai dengan pengalaman saya sendiri. Ini bukan pertama kalinya hal ini terjadi pada saya.
Saya tidak meragukan bahwa Anda mengalami masalah tersebut, tetapi ChatGPT adalah sumber yang sangat buruk karena dikenal sering mengarang fakta secara spontan (halusinasi)… Selama saya tidak melihat masalah ini di tempat lain, dari mana informasi untuk ChatGPT itu berasal? (dan LLM seperti ini sering kali tertinggal berbulan-bulan dalam hal informasi terbaru)
Anda juga belum mengatakan apakah sudah membuka tiket atau belum.
Hai,
Kami telah mengetahui masalah ini dan ingin meminta informasi lingkungan yang lebih rinci untuk membantu kami melakukan investigasi. Mohon berikan detail seperti model NAS Anda, versi firmware, aplikasi yang terpasang, atau layanan yang diaktifkan.
Terima kasih.
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
Saya baru saja mengalami masalah yang sama. Setelah mencoba menjalankan aplikasi di Container Station, antarmuka web NAS menjadi tidak responsif. Ketika saya mencoba masuk kembali, layar hanya menampilkan "Loading" biru dan tidak bergerak. Saya harus SSH dan menghentikan semua proses apache, lalu me-restart layanan thttpd.
Update: ternyata ini terjadi ketika saya secara tidak sengaja menggunakan path mount volume container yang bukan berada di share, sehingga menyebabkan ram disk penuh (cek dengan perintah "df /" via SSH).