Desktop becomes unresponsive when RAM and zram are exhausted; systemd-oomd does not intervene #130

New issue

Open

opened 2026-09-14 05:35:16 +00:00 by viniciosrab · 0 comments

viniciosrab commented

2026-09-14 05:35:16 +00:00

Describe the bug

On a custom image based on Fedora Kinoite 44 (Aurora DX NVIDIA Open), the Plasma desktop became progressively unusable under memory pressure and eventually froze instead of recovering by terminating the offending application. RAM reached 93.95%, zram swap reached 99.99%, and total CPU utilization stayed around 81–92% for roughly 30 minutes. systemd-oomd was active but did not kill anything; there were no kernel OOM-killer events either.

Aurora's maintainers stated that the relevant configuration is inherited from upstream Fedora/Kinoite and asked that this be tested/reported upstream: https://github.com/ublue-os/aurora/issues/2866#issuecomment-5659411918

VS Code (1.132.0, Electron 42.7.1, installed manually under the user's home directory) is the leading suspect, but the available historical data does not conclusively attribute per-process memory. Immediately before the ramp, two VS Code extension hosts exited/restarted. During the incident, Code repeatedly tried to scan/update an incompatible Remote-SSH extension. Near the freeze, Code's extension host and pty host became unresponsive. Chrome was also reported unresponsive at the end, so it may have been a victim or contributor.

The incident happened on 2026-09-13 between approximately 21:40 and 22:25 local time. The session then ended abruptly and the machine was rebooted.

This has not yet been reproduced on a pristine Fedora Kinoite installation. The report is being filed here because the downstream image uses Fedora's upstream systemd-oomd configuration.

Reproduction steps

The incident was not triggered intentionally and a deterministic reproducer is not yet available.

Run a Fedora Kinoite 44-based Plasma/Wayland session with the default systemd-oomd configuration and 8 GiB zram.
Use memory-intensive desktop applications until RAM and zram approach exhaustion. In the observed incident, VS Code and Chrome were active.
Observe that memory PSI may remain below the configured 80% threshold even while RAM and zram are effectively exhausted.
The desktop enters severe reclaim/thrashing and becomes unusable, without a systemd-oomd or kernel OOM kill.

I can collect per-process statistics if the issue recurs and can help test a more controlled reproducer.

Expected behavior

The desktop should remain recoverable under runaway application memory use. Ideally, the offending application/cgroup should be terminated before zram reaches 100% and the Plasma session becomes unusable. At minimum, the default oomd/cgroup configuration should prevent a complete desktop freeze and allow recovery without rebooting.

Actual behavior

The desktop progressively entered severe reclaim/thrashing as RAM and zram filled, then became unresponsive and required a reboot. systemd-oomd was running but did not intervene, and the kernel OOM killer did not log a kill.

Evidence from sysstat (sar; 12 logical CPUs, 31.2 GiB RAM, 8 GiB zram):

Time	RAM used	Swap used	CPU busy	1-min load
21:40	52.19% (17.1 GB)	47.83%	21.42%	2.57
21:50	67.25% (22.0 GB)	65.58%	91.51%	18.68
22:00	79.02% (25.9 GB)	97.40%	91.03%	17.48
22:10	90.15% (29.5 GB)	99.85%	82.08%	15.07
22:20	93.95% (30.8 GB)	99.99%	80.85%	15.89

At 22:20, only 270,608 KiB was free and 1,104 KiB of swap remained free. Kernel page scanning was 2,460 pages/s, major faults were 42.53/s, and memory PSI was about 25% (%smem), consistent with severe reclaim/thrashing.

System details

rpm-ostree status -b at the time:

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: inactive
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx-nvidia-open:stable
                   Digest: sha256:4cc7dfa929bd411be219be1349a1c91370c17660f3ce2e4f79bdfa94c7ade5f8
                  Version: 44.20260908.1 (2026-09-08T01:34:57Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx-nvidia-open:stable
                   Digest: sha256:b96bbdd864d4ef248d40fd6e5eedb1c79e3902a28981b5c862a6f97c352bbbf8
                  Version: 44.20260902.1 (2026-09-02T04:08:39Z)

Custom image based on Fedora Kinoite 44: aurora-dx-nvidia-open:stable
Kernel: 7.1.8-200.fc44.x86_64
Desktop: KDE Plasma on Wayland
Machine: desktop PC
CPU: AMD Ryzen 5 5600 (6 cores / 12 threads)
RAM: 32 GB
GPU: NVIDIA GeForce RTX 3060 Ti, open kernel module 610.57.04
zram: 8 GiB
vm.swappiness = 10

systemd-oomd state/configuration checked after reboot:

systemd-oomd.service: active (running)
Swap Used Limit: 90.00%
Default Memory Pressure Limit: 60.00%
Default Memory Pressure Duration: 20s

Memory Pressure Monitored CGroups:
  /system.slice: 80% for 20s
  /user.slice/user-1000.slice/user@1000.service: 80% for 20s
  /user.slice/user-1000.slice/user@1000.service/app.slice: 80% for 20s

Swap Monitored CGroups: (none)
vm.swappiness = 10

Additional information or screenshots

Relevant journal and VS Code timeline:

21:39:34 code: Extension host pid 2250795 exited
21:39:39 code: Extension host pid 3053315 exited
21:40 onward: repeated Remote-SSH 0.128.0 scan errors (requires Code >=1.133; installed Code is 1.132)
22:24:54 kwin_wayland: The main thread was hanging temporarily!
22:25:17 code: Extension host (pid 3053476) is unresponsive
22:25:18 code: Extension host is responsive again
22:25:20 code: No ptyHost heartbeat after 6 seconds
22:25:25 at-spi2-registryd: Disabling unresponsive app (the PID belonged to the Chrome Flatpak launch tree)
22:25:36 last journal entry from the affected boot
22:26:11 next boot begins

No Killed process, kernel Out of memory, systemd-oomd kill, NVIDIA Xid, GPU reset, or lockup event was logged during the incident window.

Other application details:

Chrome Flatpak: 153.0.8010.36
VS Code: 1.132.0 / Electron 42.7.1, manually installed in the home directory
No deliberate stress test was running.
Raw logs are not attached because they contain local paths and network addresses; relevant lines above are sanitized.

The current configuration appears to allow zram to fill completely and the desktop to thrash/freeze without oomd intervening because PSI never reached the configured 80% threshold. It would be useful to determine whether an appropriate user/app cgroup should have ManagedOOMSwap=kill, whether the desktop memory-pressure threshold should be lowered, or whether another safeguard is appropriate.

### Describe the bug On a custom image based on Fedora Kinoite 44 (Aurora DX NVIDIA Open), the Plasma desktop became progressively unusable under memory pressure and eventually froze instead of recovering by terminating the offending application. RAM reached 93.95%, zram swap reached 99.99%, and total CPU utilization stayed around 81–92% for roughly 30 minutes. `systemd-oomd` was active but did not kill anything; there were no kernel OOM-killer events either. Aurora's maintainers stated that the relevant configuration is inherited from upstream Fedora/Kinoite and asked that this be tested/reported upstream: https://github.com/ublue-os/aurora/issues/2866#issuecomment-5659411918 VS Code (1.132.0, Electron 42.7.1, installed manually under the user's home directory) is the leading suspect, but the available historical data does not conclusively attribute per-process memory. Immediately before the ramp, two VS Code extension hosts exited/restarted. During the incident, Code repeatedly tried to scan/update an incompatible Remote-SSH extension. Near the freeze, Code's extension host and pty host became unresponsive. Chrome was also reported unresponsive at the end, so it may have been a victim or contributor. The incident happened on 2026-09-13 between approximately 21:40 and 22:25 local time. The session then ended abruptly and the machine was rebooted. This has not yet been reproduced on a pristine Fedora Kinoite installation. The report is being filed here because the downstream image uses Fedora's upstream `systemd-oomd` configuration. ### Reproduction steps The incident was not triggered intentionally and a deterministic reproducer is not yet available. 1. Run a Fedora Kinoite 44-based Plasma/Wayland session with the default `systemd-oomd` configuration and 8 GiB zram. 2. Use memory-intensive desktop applications until RAM and zram approach exhaustion. In the observed incident, VS Code and Chrome were active. 3. Observe that memory PSI may remain below the configured 80% threshold even while RAM and zram are effectively exhausted. 4. The desktop enters severe reclaim/thrashing and becomes unusable, without a `systemd-oomd` or kernel OOM kill. I can collect per-process statistics if the issue recurs and can help test a more controlled reproducer. ### Expected behavior The desktop should remain recoverable under runaway application memory use. Ideally, the offending application/cgroup should be terminated before zram reaches 100% and the Plasma session becomes unusable. At minimum, the default oomd/cgroup configuration should prevent a complete desktop freeze and allow recovery without rebooting. ### Actual behavior The desktop progressively entered severe reclaim/thrashing as RAM and zram filled, then became unresponsive and required a reboot. `systemd-oomd` was running but did not intervene, and the kernel OOM killer did not log a kill. Evidence from `sysstat` (`sar`; 12 logical CPUs, 31.2 GiB RAM, 8 GiB zram): | Time | RAM used | Swap used | CPU busy | 1-min load | |---|---:|---:|---:|---:| | 21:40 | 52.19% (17.1 GB) | 47.83% | 21.42% | 2.57 | | 21:50 | 67.25% (22.0 GB) | 65.58% | 91.51% | 18.68 | | 22:00 | 79.02% (25.9 GB) | 97.40% | 91.03% | 17.48 | | 22:10 | 90.15% (29.5 GB) | 99.85% | 82.08% | 15.07 | | 22:20 | 93.95% (30.8 GB) | 99.99% | 80.85% | 15.89 | At 22:20, only 270,608 KiB was free and 1,104 KiB of swap remained free. Kernel page scanning was 2,460 pages/s, major faults were 42.53/s, and memory PSI was about 25% (`%smem`), consistent with severe reclaim/thrashing. ### System details `rpm-ostree status -b` at the time: ```text State: idle AutomaticUpdates: stage; rpm-ostreed-automatic.timer: inactive Deployments: ● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx-nvidia-open:stable Digest: sha256:4cc7dfa929bd411be219be1349a1c91370c17660f3ce2e4f79bdfa94c7ade5f8 Version: 44.20260908.1 (2026-09-08T01:34:57Z) ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx-nvidia-open:stable Digest: sha256:b96bbdd864d4ef248d40fd6e5eedb1c79e3902a28981b5c862a6f97c352bbbf8 Version: 44.20260902.1 (2026-09-02T04:08:39Z) ``` - Custom image based on Fedora Kinoite 44: `aurora-dx-nvidia-open:stable` - Kernel: `7.1.8-200.fc44.x86_64` - Desktop: KDE Plasma on Wayland - Machine: desktop PC - CPU: AMD Ryzen 5 5600 (6 cores / 12 threads) - RAM: 32 GB - GPU: NVIDIA GeForce RTX 3060 Ti, open kernel module 610.57.04 - zram: 8 GiB - `vm.swappiness = 10` `systemd-oomd` state/configuration checked after reboot: ```text systemd-oomd.service: active (running) Swap Used Limit: 90.00% Default Memory Pressure Limit: 60.00% Default Memory Pressure Duration: 20s Memory Pressure Monitored CGroups: /system.slice: 80% for 20s /user.slice/user-1000.slice/user@1000.service: 80% for 20s /user.slice/user-1000.slice/user@1000.service/app.slice: 80% for 20s Swap Monitored CGroups: (none) vm.swappiness = 10 ``` ### Additional information or screenshots Relevant journal and VS Code timeline: ```text 21:39:34 code: Extension host pid 2250795 exited 21:39:39 code: Extension host pid 3053315 exited 21:40 onward: repeated Remote-SSH 0.128.0 scan errors (requires Code >=1.133; installed Code is 1.132) 22:24:54 kwin_wayland: The main thread was hanging temporarily! 22:25:17 code: Extension host (pid 3053476) is unresponsive 22:25:18 code: Extension host is responsive again 22:25:20 code: No ptyHost heartbeat after 6 seconds 22:25:25 at-spi2-registryd: Disabling unresponsive app (the PID belonged to the Chrome Flatpak launch tree) 22:25:36 last journal entry from the affected boot 22:26:11 next boot begins ``` No `Killed process`, kernel `Out of memory`, `systemd-oomd` kill, NVIDIA Xid, GPU reset, or lockup event was logged during the incident window. Other application details: - Chrome Flatpak: 153.0.8010.36 - VS Code: 1.132.0 / Electron 42.7.1, manually installed in the home directory - No deliberate stress test was running. - Raw logs are not attached because they contain local paths and network addresses; relevant lines above are sanitized. The current configuration appears to allow zram to fill completely and the desktop to thrash/freeze without oomd intervening because PSI never reached the configured 80% threshold. It would be useful to determine whether an appropriate user/app cgroup should have `ManagedOOMSwap=kill`, whether the desktop memory-pressure threshold should be lowered, or whether another safeguard is appropriate.