From Fedora Project Wiki

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

Current status

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:
  • 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)

Release Notes