From: https://src.fedoraproject.org/rpms/fedora-release/pull-request/148
The low-memory-monitor service is used to implement the GMemoryMonitor API in GLib, and is used by a number of applications to reduce their memory footprint when needed.
See https://developer.gnome.org/gio/stable/GMemoryMonitor.html and http://www.hadess.net/2019/12/gmemorymonitor-low-memory-monitor-2nd.html
+1
Metadata Update from @chrismurphy: - Issue tagged with: meeting
This needs more information: is it intended for Fedora 33? And are there any possible conflicts/interactions with earlyoom?
@hadess @hakavlad
This needs more information: is it intended for Fedora 33?
For Fedora 32 and 33. This will need to be backported, as it was always supposed to be running to make the API available.
And are there any possible conflicts/interactions with earlyoom?
None.
We discussed this briefly at today's meeting. I don't think we're going to retroactively enable this for F32, and it's too late for F33 as well. It's not a big deal if GMemoryMonitor doesn't work in stable distros.
No decision yet for F34, but I suggest we approve this to get GMemoryMonitor working, on the understanding that OOM killing functionality will never be enabled in Fedora (as we currently use earlyoom instead, and eventually would prefer systemd-oomd). Do you have any comment on the relationship between low-memory-monitor and systemd-oomd? That's really the only concern that I see: it's would be a bit weird to have two low memory monitoring daemons running by default, although I understand systemd-oomd is unlikely to implement the GMemoryMonitor API, so they are doing two different things. The design might be more elegant if low-memory-monitor really only monitored and never killed, though.
Note that to enable this, just changing the preset will not be enough, because it was installed but disabled for F32 and F33 and Neal says presets don't affect upgraded systems. So you will need to use a %triggerun. See https://src.fedoraproject.org/rpms/systemd/blob/39055121170430fa599f454533543cec89a79a58/f/systemd.spec#_683 for an example.
It is to me...
No decision yet for F34, but I suggest we approve this to get GMemoryMonitor working, on the understanding that OOM killing functionality will never be enabled in Fedora (as we currently use earlyoom instead, and eventually would prefer systemd-oomd). Do you have any comment on the relationship between low-memory-monitor and systemd-oomd? That's really the only concern that I see: it's would be a bit weird to have two low memory monitoring daemons running by default, although I understand systemd-oomd is unlikely to implement the GMemoryMonitor API, so they are doing two different things.
Read the replies to: https://github.com/systemd/systemd/pull/15206#issuecomment-659310309
The design might be more elegant if low-memory-monitor really only monitored and never killed, though.
Fedora isn't the only user of low-memory-monitor, so the functionality will stay there, even if it is disabled by default.
systemd-oomd is unlikely to implement the GMemoryMonitor API
So, LMM has no conflict with anything.
Metadata Update from @chrismurphy: - Issue untagged with: meeting
Final freeze for Fedora 33 starts Tuesday Oct-6 1400 UTC. WG meeting starts immediately before Fedora 33. It's tight timing to decide this at the meeting, preferably it gets figured out in ticket before then, but I'm going to keep it on the agenda.
What do I need to do to get this fixed for Fedora 33 and 32, both of which are still going to be supported for at least another release cycle?
GMemoryMonitor was one of the advertised features of GNOME 3.36: https://help.gnome.org/misc/release-notes/3.36/developers.html.en
Looks like it was agreed, I'll mention this in the merge request. https://meetbot.fedoraproject.org/fedora-meeting-2/2020-10-07/workstation.2020-10-07-04.38.html
Oops, looks like we forgot to update this issue. Yes, we agreed to allow this in late for F33 (even though it's really late. ;) You'll need to merge the fedora-release change first (and get a freeze exception for it), then update low-memory-monitor RPM to toggle the preset for users upgrading from F32, as demonstrated by the systemd package scriptlet that enables systemd-resolved (no freeze exception needed here because this change only affects users upgrading from F32).
As for F32... adding a new daemon six months after the release is aggressive. Nothing should break if it's not running, just applications using GMemoryMonitor won't get memory status updates. So we didn't approve this for F32.
Metadata Update from @catanzaro: - Issue untagged with: meeting - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.