Drop low-memory-monitor package
Summary
Modern GLib (GMemoryMonitor) introduces memory monitor backends that run independently without relying on an external daemon to send low-memory signals to applications. Previously, low-memory-daemon was the sole provider of these events. Since GLib no longer requires low-memory-monitor to deliver these notifications and it is an archived project, low-memory-monitor can be dropped.
Owner
- Name: Kate Hsuan
- Email: hpa@redhat.com
Current status
- Targeted release: Fedora Linux 46
- Last updated: 2026-09-02
- Announced
- Discussion thread
- FESCo issue: #3671
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
With the introduction of native GMemoryMonitor backends [1-2] in GLib (including Linux kernel Pressure Stall Information (PSI) monitoring and a fallback polling mechanism), GLib can now monitor local memory usage directly. Previously, applications relied on an external background service, low-memory-monitor, via D-Bus to receive low-memory signals. The new Linux PSI backend actively monitors kernel-level resource pressure and emits signals to GMemoryMonitor subscribers when memory limits are reached. If PSI is disabled or unavailable, the fallback backend polls system memory metrics directly.
Because GMemoryMonitor no longer requires a dedicated external daemon to function, low-memory-monitor can be dropped. However, GLib retains the legacy D-Bus backend for low-memory-monitor to ensure backward compatibility with older distributions.
[1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4481
[2] https://systemd.io/PRESSURE/
Feedback
See https://systemd.io/PRESSURE/
Benefit to Fedora
Since GMemoryMonitor can run without an external service, low-memory-monitor can be deprecated. The runtime usage is reduced by stopping running low-memory-monitor.
Scope
- Proposal owners: Kate Hsuan
- Other developers:
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with the Fedora Strategy:
Upgrade/compatibility impact
Glib2 manages all the dependencies and GMemoryMonitor runs independently, so upgrade/compatibility won't be impacted.
Early Testing (Optional)
Do you require 'QA Blueprint' support? Y/N
How To Test
1. Make a test code from the example code mentioned in the documents [1].
2. Compile and run the test program in a memory-limited system.
3. Stree the memory until the signal is emitted.
[1] https://docs.gtk.org/gio/iface.MemoryMonitor.html
User Experience
Dependencies
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
Bring back the low-memory-monitor package since the Dbus backend of GMemoryMonitor is still there.
Documentation
N/A (not a System Wide Change)
