Tracking down Core crashes

[bacco007]

My setup had been rocksolid until two weeks ago when it would core would crash out and leave no real signs of why. Sometimes it’s instant, sometimes it’s several hours and the other day I got several days.

I run my HAOS in a proxmox environment, has access to 28Gb ram and plenty of storage. I noticed this morning after it crashed again that the host logs were mentioning that timesyncd is reporting that the network config changed regularly

I want to get this fixed once and for all, but I’m not sure where to start. I’ve disabled all of the custom components I’ve been using as a starting point. When core crashes it doesn’t leave any reason, but the host logs leave this

2025-09-15 21:05:46.031 homeassistant systemd-coredump[17697]: Process 6682 (python3) of user 0 terminated abnormally with signal 11/SEGV, processing…
2025-09-15 21:05:46.035 homeassistant systemd[1]: Created slice Slice /system/systemd-coredump.
2025-09-15 21:05:46.037 homeassistant systemd[1]: Started Process Core Dump (PID 17697/UID 0).
2025-09-15 21:05:46.061 homeassistant systemd-timesyncd[736]: Network configuration changed, trying to establish connection.
2025-09-15 21:05:46.068 homeassistant systemd-timesyncd[736]: Network configuration changed, trying to establish connection.
2025-09-15 21:05:46.088 homeassistant systemd-timesyncd[736]: Network configuration changed, trying to establish connection.
2025-09-15 21:05:46.106 homeassistant systemd-timesyncd[736]: Contacted time server 162.159.200.1:123 (time.cloudflare.com).
2025-09-15 21:05:46.183 homeassistant systemd-coredump[17698]: Process 6682 (python3) of user 0 terminated abnormally without generating a coredump.
2025-09-15 21:05:46.190 homeassistant systemd[1]: [email protected]: Deactivated successfully.
2025-09-15 21:05:49.361 homeassistant systemd[1]: docker-0a557a3e1e0e7dace9bfe2dfb8dcbe7bc99f53448571f266e1374aa7de9bbe03.scope: Deactivated successfully.
2025-09-15 21:05:49.361 homeassistant systemd[1]: docker-0a557a3e1e0e7dace9bfe2dfb8dcbe7bc99f53448571f266e1374aa7de9bbe03.scope: Consumed 9min 25.240s CPU time, 5.7G memory peak, 622.4M read from disk, 427.2M written to disk.
2025-09-15 21:05:49.368 homeassistant dockerd[758]: time=“2025-09-16T07:05:49.368958990+10:00” level=info msg=“ignoring event” container=0a557a3e1e0e7dace9bfe2dfb8dcbe7bc99f53448571f266e1374aa7de9bbe03 module=libcontainerd namespace=moby topic=/tasks/delete type=“*events.TaskDelete”
2025-09-15 21:05:49.390 homeassistant systemd[1]: var-lib-docker-overlay2-528c3d51006e1ce72a7078d19683a2b27e7031b1953b68085c2a1a43ab87971f-merged.mount: Deactivated successfully.
2025-09-15 21:05:49.390 homeassistant systemd[1]: mnt-data-docker-overlay2-528c3d51006e1ce72a7078d19683a2b27e7031b1953b68085c2a1a43ab87971f-merged.mount: Deactivated successfully.

Any ideas how I can chase a possible fix down? This is getting frustrating.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Hello bacco007,

2024.5+: Tracking down instability issues caused by integrations

If your system is unstable due to a misbehaving integration, there are several ways to identify and recover from the issue. It’s recommended to enable Home Assistant’s debug mode and asyncio debug mode to collect detailed logs and diagnose the root cause. Using Home Assistant's Built-In Debug Mode (2024.5.x or later – Recommended) Enabling Asyncio Debug Mode at Runtime (Preferred with Debug Mode) Enabling Asyncio Debug Before Startup (Fallback Plan) 🛠️ Manually Enabling Safe Mod…

[bacco007]

None of these options has gotten me closer to working out what’s going on, although this time i got a .log.fault file:

Fatal Python error: Segmentation fault

[cginebrosa]

Hi,

I’m having exactly the same problem with a Raspberry Pi 4 using a 128GB SSD disk (not an SD card).

Perfectly running until some weeks ago.

I noticed that CPU goes crazy to 100%, and looking at glances, it’s the homeassistant container itself.

Tried to disable all custom components and all addons but the problem persists.

Some times it restarts in a couple of minutes, sometimes in a couple of hours.

Downgraded up to 2025.9.1, but this doesn’t solve the problem.

In the host log always appear these messages:

2025-09-23 05:22:37.848 homeassistant systemd-coredump[53572]: Process 52401 (python3) of user 0 terminated abnormally with signal 11/SEGV, processing…

2025-09-23 05:22:37.869 homeassistant systemd[1]: Started Process Core Dump (PID 53572/UID 0).

2025-09-23 05:22:37.938 homeassistant systemd-timesyncd[636]: Network configuration changed, trying to establish connection.

2025-09-23 05:22:37.945 homeassistant systemd-timesyncd[636]: Contacted time server 162.159.200.1:123 (time.cloudflare.com).

2025-09-23 05:22:37.993 homeassistant systemd-timesyncd[636]: Network configuration changed, trying to establish connection.

2025-09-23 05:22:37.997 homeassistant systemd-timesyncd[636]: Contacted time server 162.159.200.1:123 (time.cloudflare.com).

2025-09-23 05:22:38.162 homeassistant systemd-timesyncd[636]: Network configuration changed, trying to establish connection.

2025-09-23 05:22:38.166 homeassistant systemd-timesyncd[636]: Contacted time server 162.159.200.1:123 (time.cloudflare.com).

2025-09-23 05:22:38.831 homeassistant systemd-coredump[53573]: Process 52401 (python3) of user 0 terminated abnormally without generating a coredump.

And then, in supervisor log that ones (time is in CET+2 in supervisor):

2025-09-23 07:22:39.089 WARNING (MainThread) [supervisor.homeassistant.websocket] Connection is closed

2025-09-23 07:22:39.112 INFO (MainThread) [supervisor.api.proxy] [a0d7b954_nodered] Home Assistant WebSocket API closed

2025-09-23 07:22:42.644 WARNING (MainThread) [supervisor.homeassistant.core] Watchdog found Home Assistant failed, restarting…

Any help will be appreciated,
Carlos

[cginebrosa]

Now HA is running without restart for 16 hours, but CPU is 100% from 15 hours ago.

Here is a screenshot from Glances where is clear that is python3 inside HA container who is consuming the CPU.

[cginebrosa]

Hi,

After some investigations, I’m pretty sure the responsible is Meteoclimatic integration, a native integration in Homeassistant…at least in my installation.

Seems something related to SSL handshake.

The following thread is always present as current thread in home-assistant.log.fault

Current thread 0x0000007f9bf6e3e0 (most recent call first):
File “/usr/local/lib/python3.13/ssl.py”, line 1372 in do_handshake
File “/usr/local/lib/python3.13/ssl.py”, line 1076 in _create
File “/usr/local/lib/python3.13/ssl.py”, line 455 in wrap_socket
File “/usr/local/lib/python3.13/http/client.py”, line 1479 in connect
File “/usr/local/lib/python3.13/http/client.py”, line 1037 in send
File “/usr/local/lib/python3.13/http/client.py”, line 1093 in _send_output
File “/usr/local/lib/python3.13/http/client.py”, line 1333 in endheaders
File “/usr/local/lib/python3.13/http/client.py”, line 1384 in _send_request
File “/usr/local/lib/python3.13/http/client.py”, line 1338 in request
File “/usr/local/lib/python3.13/urllib/request.py”, line 1319 in do_open
File “/usr/local/lib/python3.13/urllib/request.py”, line 1367 in https_open
File “/usr/local/lib/python3.13/urllib/request.py”, line 466 in _call_chain
File “/usr/local/lib/python3.13/urllib/request.py”, line 506 in _open
File “/usr/local/lib/python3.13/urllib/request.py”, line 489 in open
File “/usr/local/lib/python3.13/urllib/request.py”, line 189 in urlopen
File “/usr/local/lib/python3.13/site-packages/meteoclimatic/client.py”, line 20 in weather_at_station
File “/usr/local/lib/python3.13/concurrent/futures/thread.py”, line 59 in run
File “/usr/local/lib/python3.13/concurrent/futures/thread.py”, line 93 in _worker
File “/usr/local/lib/python3.13/threading.py”, line 994 in run
File “/usr/local/lib/python3.13/threading.py”, line 1043 in _bootstrap_inner
File “/usr/local/lib/python3.13/threading.py”, line 1014 in _bootstrap

The strange thing is that this error seems to occur ONLY WITH SOME STATIONS and not everytime it tries to get station data…sometimes it works fine for 1 hour, sometimes for 10 hours…sometimes for 10 minutes.

If I disable all stations no crash for 5 days…after reenabling some of them the problem appears, so right now I only have enabled one of the suspected stations for testing: ESCAT2500000025566A

If no problem occur within 24 hours I will enable the others one by one to confirm my suspicions.

@bacco007 do you have Meteoclimatic integration active?

Keep you updated

[bacco007]

@cginebrosa

do you have Meteoclimatic integration active?

No I dont, I discovered for me it was the fastdotcom integration

[cginebrosa]

Now I changed my suspicions to AEMET integration.

Even Meteoclimatic is ALWAYS the current thread at crash time, I’ve seen many errors within AEMET whilst no errors on Meteoclimatic:

2025-10-04 10:06:04.979 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

2025-10-04 10:06:05.026 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

2025-10-04 10:06:05.031 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

2025-10-04 10:06:05.092 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

2025-10-04 10:06:05.110 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

2025-10-04 10:06:05.112 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

2025-10-04 10:06:11.128 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

2025-10-04 10:06:11.130 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

2025-10-04 10:06:11.146 ERROR (MainThread) [aemet_opendata.interface] Server disconnected

and I think MAYBE the root cause may lie in the storm of AEMET errors (too many requests + server disconnected) that overload the event loop.

Just disabled AEMET and reenabled all Meteoclimatic stations for testing.

[cginebrosa]

No way to find the real reason of the crashes.

Anyway, I upgraded to HA 2025.10.0 and crashes stopped without changing any other configuration.

Now I’m in 2025.10.2 and everything continues fine.