kde/tracker

Fork 0

Kinoite: systemd-oomd does not intervene before desktop freeze under extreme memory pressure #728

New issue

Open

opened 2026-09-14 09:23:29 +00:00 by viniciosrab · 0 comments

viniciosrab commented

2026-09-14 09:23:29 +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 severe memory pressure and eventually froze instead of recovering by terminating a memory-consuming application.

During the incident, RAM reached 93.95%, zram swap reached 99.99%, and total CPU utilization remained around 81–92% for roughly 30 minutes. systemd-oomd was active, but it did not kill anything. There were also no kernel OOM-killer events.

After reboot, systemd-oomd reported the following configuration:

Swap Used Limit: 90%
Default Memory Pressure Limit: 60%
/system.slice: 80% for 20s
user@1000.service: 80% for 20s
app.slice: 80% for 20s
Swap Monitored CGroups: none

Observed memory PSI reached approximately 25%, well below the configured 80% pressure threshold, even though RAM and zram were almost completely exhausted.

This has not yet been reproduced on a pristine Fedora Kinoite installation.

VS Code is the leading suspect for the memory consumption, but the available historical data is not sufficient to conclusively attribute the memory usage to a specific process.

Reproduction steps

A deterministic reproducer is not currently available. The original incident was not triggered intentionally.

Approximate conditions from the observed incident:

Run a Fedora Kinoite 44-based Plasma/Wayland session using the default Fedora systemd-oomd configuration.
Have several memory-intensive desktop applications running. In the observed incident, VS Code and Chrome were active.
Increase memory usage until physical RAM and zram are nearly exhausted.
Observe memory pressure and system responsiveness.

In the observed incident:

RAM usage increased to about 94%.
zram swap increased to essentially 100%.
Memory PSI remained around 25%, below the configured 80% systemd-oomd threshold.
The machine entered severe reclaim/thrashing.
systemd-oomd did not kill a cgroup.
The kernel OOM killer did not kill a process.
Plasma eventually became unusable and the machine had to be rebooted.

I can collect per-process/cgroup statistics and attempt a controlled reproducer if the issue occurs again.

Expected behavior

The desktop should remain recoverable when an application or cgroup consumes excessive memory.

Ideally, the offending application/cgroup should be terminated before zram reaches 100% and the Plasma session becomes unusable.

At minimum, Fedora Kinoite's default memory-pressure/OOM configuration should prevent prolonged reclaim/thrashing from making the entire desktop unusable and requiring a reboot.

Actual behavior

The desktop progressively entered severe reclaim/thrashing as RAM and zram filled, then became unresponsive and required a reboot.

systemd-oomd remained active but did not kill anything, and there was no kernel OOM-killer event.

Evidence from sysstat/sar:

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 of RAM was free.
Only 1,104 KiB of swap remained free.
Kernel page scanning was approximately 2,460 pages/s.
Major faults were approximately 42.53/s.
Memory PSI was approximately 25%.
The Plasma session was becoming unusable.

No systemd-oomd kill or kernel OOM kill was logged.

System details

Custom image based on Fedora Kinoite 44:
Aurora DX NVIDIA Open (aurora-dx-nvidia-open:stable)

rpm-ostree status -b:

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)

Hardware/software:

Kernel: 7.1.8-200.fc44.x86_64
Desktop: KDE Plasma / Wayland
Machine: Desktop PC
CPU: AMD Ryzen 5 5600, 6 cores / 12 threads
RAM: 32 GB
GPU: NVIDIA GeForce RTX 3060 Ti
NVIDIA driver/open kernel module: 610.57.04
zram: 8 GiB
vm.swappiness = 10

Additional information or screenshots

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

systemd-oomd 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

Relevant journal / application 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
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
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.

Applications active during the incident:

Chrome Flatpak: 153.0.8010.36
VS Code: 1.132.0 / Electron 42.7.1
VS Code was installed manually under the user's home directory.
Remote-SSH extension 0.128.0 required Code >= 1.133 and was repeatedly being scanned/updated.
No deliberate memory stress test was running.

VS Code is the leading suspect, but the historical data does not provide sufficient per-process memory information to prove that it was the source of the memory exhaustion. Chrome may also have been either a contributor or a victim.

Raw logs are not attached because they contain local filesystem paths and network addresses. Relevant lines above have been sanitized.

What seems particularly relevant is that zram was effectively 100% full while memory PSI remained well below the configured 80% pressure threshold. Additionally, systemd-oomd reported no Swap Monitored CGroups.

It may be worth investigating whether an appropriate user/app cgroup should use ManagedOOMSwap=kill, whether the default memory-pressure threshold is appropriate for an interactive Plasma desktop, or whether another safeguard should handle this condition.

### Describe the bug On a custom image based on Fedora Kinoite 44 (Aurora DX NVIDIA Open), the Plasma desktop became progressively unusable under severe memory pressure and eventually froze instead of recovering by terminating a memory-consuming application. During the incident, RAM reached 93.95%, zram swap reached 99.99%, and total CPU utilization remained around 81–92% for roughly 30 minutes. systemd-oomd was active, but it did not kill anything. There were also no kernel OOM-killer events. After reboot, systemd-oomd reported the following configuration: - Swap Used Limit: 90% - Default Memory Pressure Limit: 60% - /system.slice: 80% for 20s - user@1000.service: 80% for 20s - app.slice: 80% for 20s - Swap Monitored CGroups: none Observed memory PSI reached approximately 25%, well below the configured 80% pressure threshold, even though RAM and zram were almost completely exhausted. This has not yet been reproduced on a pristine Fedora Kinoite installation. VS Code is the leading suspect for the memory consumption, but the available historical data is not sufficient to conclusively attribute the memory usage to a specific process. ### Reproduction steps A deterministic reproducer is not currently available. The original incident was not triggered intentionally. Approximate conditions from the observed incident: 1. Run a Fedora Kinoite 44-based Plasma/Wayland session using the default Fedora systemd-oomd configuration. 2. Have several memory-intensive desktop applications running. In the observed incident, VS Code and Chrome were active. 3. Increase memory usage until physical RAM and zram are nearly exhausted. 4. Observe memory pressure and system responsiveness. In the observed incident: - RAM usage increased to about 94%. - zram swap increased to essentially 100%. - Memory PSI remained around 25%, below the configured 80% systemd-oomd threshold. - The machine entered severe reclaim/thrashing. - systemd-oomd did not kill a cgroup. - The kernel OOM killer did not kill a process. - Plasma eventually became unusable and the machine had to be rebooted. I can collect per-process/cgroup statistics and attempt a controlled reproducer if the issue occurs again. ### Expected behavior The desktop should remain recoverable when an application or cgroup consumes excessive memory. Ideally, the offending application/cgroup should be terminated before zram reaches 100% and the Plasma session becomes unusable. At minimum, Fedora Kinoite's default memory-pressure/OOM configuration should prevent prolonged reclaim/thrashing from making the entire desktop unusable and requiring a reboot. ### Actual behavior The desktop progressively entered severe reclaim/thrashing as RAM and zram filled, then became unresponsive and required a reboot. systemd-oomd remained active but did not kill anything, and there was no kernel OOM-killer event. Evidence from sysstat/sar: | 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 of RAM was free. - Only 1,104 KiB of swap remained free. - Kernel page scanning was approximately 2,460 pages/s. - Major faults were approximately 42.53/s. - Memory PSI was approximately 25%. - The Plasma session was becoming unusable. No systemd-oomd kill or kernel OOM kill was logged. ### System details Custom image based on Fedora Kinoite 44: Aurora DX NVIDIA Open (aurora-dx-nvidia-open:stable) rpm-ostree status -b: 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) Hardware/software: - Kernel: 7.1.8-200.fc44.x86_64 - Desktop: KDE Plasma / Wayland - Machine: Desktop PC - CPU: AMD Ryzen 5 5600, 6 cores / 12 threads - RAM: 32 GB - GPU: NVIDIA GeForce RTX 3060 Ti - NVIDIA driver/open kernel module: 610.57.04 - zram: 8 GiB - vm.swappiness = 10 ### Additional information or screenshots The incident occurred on 2026-09-13 between approximately 21:40 and 22:25 local time. The affected session ended abruptly and the machine was rebooted. systemd-oomd 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 Relevant journal / application 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 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 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. Applications active during the incident: - Chrome Flatpak: 153.0.8010.36 - VS Code: 1.132.0 / Electron 42.7.1 - VS Code was installed manually under the user's home directory. - Remote-SSH extension 0.128.0 required Code >= 1.133 and was repeatedly being scanned/updated. - No deliberate memory stress test was running. VS Code is the leading suspect, but the historical data does not provide sufficient per-process memory information to prove that it was the source of the memory exhaustion. Chrome may also have been either a contributor or a victim. Raw logs are not attached because they contain local filesystem paths and network addresses. Relevant lines above have been sanitized. What seems particularly relevant is that zram was effectively 100% full while memory PSI remained well below the configured 80% pressure threshold. Additionally, systemd-oomd reported no Swap Monitored CGroups. It may be worth investigating whether an appropriate user/app cgroup should use ManagedOOMSwap=kill, whether the default memory-pressure threshold is appropriate for an interactive Plasma desktop, or whether another safeguard should handle this condition.

viniciosrab added the

kinoite

label

2026-09-14 09:23:29 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

kde/tracker#728

No description provided.

Rows
Columns