Was there ever any discussion of a "memory low" signal?

[ell1e]

Feature request in short: This isn't really a question limited to earlyoom, but as an app dev I wonder if in the freedesktop and Unix community as a whole, was there ever any design ideas floating around of a "memory low" signal?

How could it work: This could either be one of the signals like SIGUSR2 (although the default of many to just terminate the process is regrettable), or some dbus service thing to subscribe to (dbus can be complicated to hook into without kind of big helper libraries though), some Unix socket for any app that is interested to listen to, or something like that.

It should be some mechanism where before earlyoom needs to shoot down something, it can go to the top N big offenders that would be in the most favorite slots to shoot down soon, and tell them "hey, memory is running low, please adjust before my hand is forced". If one of the big offenders happens to understand the signal and reacts, then great, crisis averted. If none does, eventually the usual SIGTERM kicks in.

Why this could be great: I believe Android has this. It would be infinitely less jarring for the user, if e.g. a browser that may already be employing some sort of memory saver mechanism, would automatically turn it on or dial it up in response, and unload unused tabs for example.

Especially non-techie users won't understand why some programs just silently terminate, or they'll find it frustrating even if somebody explains to them that there's a good reason.

What alternatives might there be: I've seen some apps like Firefox attempt to implement this on their own, but usually it comes down to: 1. there is some weird corner case, like ZFS, that affects numbers weirdly so that for some users it'll do really undesirable things thinking there is low memory when there isn't, 2. therefore it's never ever going to be turned on by default ever.

Sadly, therefore I don't think a solution as some sort of library used by apps will ever work. Meanwhile, in earlyoom I think this can work, since e.g. a Linux distribution could ship a different default config for it when ZFS is picked in the distro installer, or something like that.

Summed up: Please consider implementing such a signal for apps to hook into, or perhaps it might be worth poking the freedesktop or systemd folks about some sort of unified plan to make this happen.

[rfjakob]

I agree that it makes sense, but I have never heard of anything like it.

[ell1e]

For android it exists, it's called onLowMemory: https://developer.android.com/reference/android/app/Application.html#onLowMemory%28%29 https://stackoverflow.com/questions/7360102/how-does-onlowmemory-work-on-android

[rfjakob]

Actually, here is something: https://gitlab.freedesktop.org/hadess/low-memory-monitor !

Fedora and Debian seem to be shipping the package, but the git repo says it's archived.

[ell1e]

I wonder, does systemd-oomd have a dbus-signal then?

I wish there was a way outside of dbus though, it seems over-engineered: https://dbus.freedesktop.org/doc/dbus-tutorial.html To me the amount of concepts here listed just to get a simple "I want to know when XYZ happens" seems mind-boggling. And I think glib, with the recommended glib dbus, is written to panic when out of memory instead of transparently returning a failure which seems incompatible with how a ton of C/C++ code works. Seems like freedesktop's original libdbus doesn't have the out of memory panic problem, at least, I've just poked around the code a little bit.

[ell1e]

Okay, I found a ticket for systemd-oomd: systemd/systemd#23606 Based on this, there's a freedesktop dbus signal but systemd-oomd doesn't currently implement or trigger it. I think that would be a useful thing to have in earlyoom if ever possible, but perhaps a simpler mechanism outside of dbus would be nice on top of this. (E.g., I don't know, some sort of Unix socket to listen to which periodically gives some sort of binary signal if memory pressure is currently considered high or not.)

[rfjakob]

dbus is a beast, yes, but I'm afraid it's still the best option. Or varlink, maybe ( https://varlink.org/ ).

As for d-bus libs, I have had success with libsystemd's sd-bus: https://github.com/rfjakob/systembus-notify

[ell1e]

Using systemd to make bloated dbus "easier" doesn't seem like what developers critical of dbus would be likely to go for. It seems like a Unix socket can be opened and listened to by multiple processes, that sounds like an easy solution.

In any case, having a low memory signal even just through dbus would be useful.

[ell1e]

Okay, I've read some of Varlink now, I gotta admit it looks saner than dbus. I kind of like it.