Hi HA’ers,
I’ve had a HomeAssistant setup that has been running flawlessly up until about 2 weeks ago. I noticed it had stopped responding on the web port, although SSH is still up (both for the HA OS and the HA container). This took a day or two to crash out initially, but now can be as quick as 10 minutes. Its unpredictable, which is odd.
Looking at the log, it ends up with the following spammed:
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 101, in close
RuntimeError: Cannot close a running event loop
2025-11-15 12:02:52.884 ERROR (MainThread) [homeassistant] Error doing job: socket.accept() out of system resource (None)
Traceback (most recent call last):
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 178, in _accept_connection
File "/usr/local/lib/python3.13/socket.py", line 295, in accept
OSError: [Errno 24] No file descriptors available
2025-11-15 12:02:52.884 ERROR (MainThread) [homeassistant] Fatal error '[Errno 24] No file descriptors available' raised in event loop, shutting it down
2025-11-15 12:02:52.884 ERROR (MainThread) [asyncio] Unhandled error in exception handler
context: {'message': 'socket.accept() out of system resource', 'exception': OSError(24, 'No file descriptors available'), 'socket': <asyncio.TransportSocket fd=12, family=2, type=1, proto=6, laddr=('0.0.0.0', 8123)>}
Traceback (most recent call last):
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 178, in _accept_connection
File "/usr/local/lib/python3.13/socket.py", line 295, in accept
OSError: [Errno 24] No file descriptors available
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.13/asyncio/base_events.py", line 1933, in call_exception_handler
self._exception_handler(self, context)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/runner.py", line 251, in _async_loop_exception_handler
loop.close()
~~~~~~~~~~^^
File "/usr/local/lib/python3.13/asyncio/unix_events.py", line 70, in close
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 101, in close
RuntimeError: Cannot close a running event loop
I understand this is typically due to miscreant integrations / plugins, and has been exacerbated since a recent release, however I’m not seeing anything in the runup to the failure to indicate something going haywire. If I watch the lsof size, it stays pretty much constant, undulating up and down a little (untill presumably it doesn’t - but I’ve never actually seen it happen as it releases all of them once it crashes).
Is there any way to begin debugging this? It seems a shame that the supervisor doesn’t bounce it (should it?), and I’m at a loss as to how to start chasing this down - I have rather a lot of integrations and trial and error may be difficult.
Version and installation info:
~ ha core info
arch: amd64
audio_input: null
audio_output: null
backups_exclude_database: false
boot: true
image: ghcr.io/home-assistant/qemux86-64-homeassistant
ip_address: 172.30.32.1
machine: qemux86-64
port: 8123
ssl: true
update_available: true
version: 2025.11.1
version_latest: 2025.11.2
watchdog: false
➜ ~ ha supervisor info
addons:
- icon: true
name: Advanced SSH & Web Terminal
repository: a0d7b954
slug: a0d7b954_ssh
state: started
update_available: true
version: 22.0.0
version_latest: 22.0.1
- icon: true
name: File editor
repository: core
slug: core_configurator
state: unknown
update_available: false
version: 5.8.0
version_latest: 5.8.0
- icon: true
name: Let's Encrypt
repository: core
slug: core_letsencrypt
state: stopped
update_available: false
version: 5.4.9
version_latest: 5.4.9
- icon: true
name: ESPHome Device Builder
repository: 5c53de3b
slug: 5c53de3b_esphome
state: started
update_available: false
version: 2025.10.5
version_latest: 2025.10.5
- icon: true
name: Ecowitt HTTP Proxy
repository: 1d2e7f3c
slug: 1d2e7f3c_ecowitt-proxy
state: unknown
update_available: false
version: 1.1.1
version_latest: 1.1.1
- icon: true
name: Cloudflared
repository: 9074a9fa
slug: 9074a9fa_cloudflared
state: started
update_available: false
version: 6.0.5
version_latest: 6.0.5
- icon: false
name: openWakeWord
repository: core
slug: core_openwakeword
state: unknown
update_available: false
version: 2.1.0
version_latest: 2.1.0
- icon: true
name: Whisper
repository: core
slug: core_whisper
state: unknown
update_available: false
version: 3.0.1
version_latest: 3.0.1
- icon: true
name: Piper
repository: core
slug: core_piper
state: unknown
update_available: false
version: 2.1.1
version_latest: 2.1.1
- icon: true
name: Mosquitto broker
repository: core
slug: core_mosquitto
state: started
update_available: false
version: 6.5.2
version_latest: 6.5.2
addons_repositories:
- name: Local add-ons
slug: local
- name: Ecowitt Proxy add-on repository
slug: 1d2e7f3c
- name: Cloudflared
slug: 9074a9fa
- name: Music Assistant
slug: d5369777
- name: Official add-ons
slug: core
- name: Home Assistant Community Add-ons
slug: a0d7b954
- name: ESPHome
slug: 5c53de3b
arch: amd64
auto_update: true
channel: stable
country: GB
debug: false
debug_block: false
detect_blocking_io: false
diagnostics: null
I’m currently watching the open fds for the homeassistant container and its rock steady:
Sun Nov 16 19:28:43 GMT 2025
154 python3 /proc/67
11 go2rtc /proc/112
7 s6-svscan /proc/1
7 s6-supervise /proc/65
7 s6-supervise /proc/26
7 s6-supervise /proc/25
7 s6-supervise /proc/16
5 s6-linux-init-s /proc/18
4 bash /proc/5029
3 sort /proc/5030
Also the only real errors i’m seeing on the logs are around a dodgy template i’ve got (which dissapears very quickly once its got data), and google homegraph (again dissapears quickly.