systemd 253 RC1 Released With New "ukify" Tool

[_ReD_]

So what exactly does systemd-oomd do, other than oom-D?

Basically it intervenes sooner, it's aware of cgroups and has some further configurability.

While it can be a very good tool in tightly controlled environments such as servers, the current approach is a clusterfuck on the desktop.
Nobody likes it when their apps, or even their entire desktops, suddenly disappear with no warnings, no clues, no way to appeal, and no way to recover anything.

There's a missing link here. The tool is too blunt and there's no instrumentation in the desktop.

Now, for this or -any other- proactive oom-handler to be viable on the desktop, integration and more functionality are imperative.
I mean, currently It's criminal! There's not even a notification after the fact.

For general acceptance we need desktop-centric functionality, a GIU for easy configuration by laypeople, and some sweeteners:
- in-advance warnings, with the options to opt-out and leave it to the kernel, or just kill stuff manually?
- an option to freeze the offenders to disk and recover them later? (There's plumbing is in the kernel, but it needs to be leveraged.)
- User-customizable policies that do not require cgroups wizardry to hint the oom-handler on how to handle specific programs and situations? (eg: signal certain apps to "save-and-exit" instead of just killing 'em dead, fail others in some specific ways, just SIGSTOP that one and leave it alone, never-ever even go near this peeve of mine, etc.)

Any of the above would improve the Desktop-OOM situation greatly, but they all require concerted efforts, resources, and time. So, we'll have to be patient...

[Old Grouch]

Is some graphics designer taking the mickey? The logo associated with the systemd name in the article looks like the symbols on media players for 'record' and 'reverse'

Wikipedia: Standard media player symbols

...the implication being that systemd is copying something and going backwards. Surely that's not the image whoever designed it wants to portray?

[Alexmitter]

Nobody likes it when their apps, or even their entire desktops, suddenly disappear with no warnings

That some distros (kough kough Ubuntu) had chosen bad defaults that caused issues on low ram machines, stuff getting killed is better then a frozen system starved of ram.
Also, the log clearly states what happens, I think what you may want is some kind of user facing notification for that case. I think something l think can be beneficial but that is hardly in the scope of the systemd-oomd project.

[cynic]

Basically it intervenes sooner, it's aware of cgroups and has some further configurability.

While it can be a very good tool in tightly controlled environments such as servers, the current approach is a clusterfuck on the desktop.
Nobody likes it when their apps, or even their entire desktops, suddenly disappear with no warnings, no clues, no way to appeal, and no way to recover anything.

There's a missing link here. The tool is too blunt and there's no instrumentation in the desktop.

I might agree with you on the topics, but the desktop instrumentation should be a distro responsibility, not one of the systemd developers.

[evil_core]

'ukify' sounds like a feature that changes your wallpaper to Ukraine flag every boot

When I was reading"ukify" it resembled "ukies" for me (it's how russians calls ukrainians on english forums)

[ClosedSource]

Each new version of it brings less and less trust for me!

Generally speaking, you can't trust software projects not to have their own agendas for their own benefit, their companies, and their clients.

Edit: This is expected and it keeps the software industry heatthy.

[_ReD_]

Also, the log clearly states what happens, I think what you may want is some kind of user facing notification for that case.

Well, laypersons don't watch, or even understand logs. So... That's exactly what I was arguing for—at a bare minimum—: "some kind of user facing notification".

I think something l think can be beneficial but that is hardly in the scope of the systemd-oomd project.

I agree. This very basic need can be solved at desk-environment, or even at distro level.

But the kind of integration I'm arguing for requires multi-stakeholders interest.
From the definition of "technology-enabling" specs, to the oom-managers abiding and evolving to match, to the desktop-environments choosing to implement, to as many apps hopefully opting-in (eg. to conventions on signal-handling), all the way down to the downstream distros.

[_ReD_]

Generally speaking, you can't trust software projects not to have their own agendas for their own benefit, their companies, and their clients.

Whatever happened to "innocent until proven guilty"...

[_ReD_]

I might agree with you on the topics, but the desktop instrumentation should be a distro responsibility, not one of the systemd developers.

While I didn't even mention systemd developers once, It's not that simple... Please also see #17 on this thread.

[andyprough]

That some distros (kough kough Ubuntu) had chosen bad defaults that caused issues on low ram machines, stuff getting killed is better then a frozen system starved of ram.
Also, the log clearly states what happens, I think what you may want is some kind of user facing notification for that case. I think something l think can be beneficial but that is hardly in the scope of the systemd-oomd project.

Thus the problem! As I said at the beginning, systemd developers are now going to spend years of their productive lives constantly fixing up just this one oomd area just because they stuck their noses into something that is more properly the realm of responsibility of the distro developers. When you don't follow the "do one thing and do it well" maxim, you get stuck with long-term responsibility for problems that are outside your area of expertise or focus.