On Tue, Aug 23, 2022 at 08:33:45AM -0400, Hendrik Boom wrote:
> On Mon, Aug 22, 2022 at 05:31:58PM +0200, Didier Kryn wrote:
> > Le 20/08/2022 à 10:20, Martin Steigerwald a écrit :
> > > oomd may make sense in certain cloud based workloads, maybe, just maybe.
> > > However… on a desktop? You are frigging kidding me, aren't you?
> >
> >     Well, it can happen to anybody to write an application which leaks
> > memory. The oom killer is automatically launched by the kernel when memory
> > pressure is too high, and it is a necessity. The problem here is with
> > systemd's oom killer, and/or with Gnome.
>
> Just wondering ... Is there a way to tell the oom killer which
> processes to preferentially kill? And which ones are worth keeping
> around?
>
> It would have to be done ahead of time, of course, because once memory
> is so overextended that the oom killer is needed, it's often futile to
> try to enter commands.

There is. See a documentation for oom_score_adj file in
https://www.kernel.org/doc/Documentation/filesystems/proc.txt

> Is there a way to keep the response on the system console (on my
> machine that's the ctl-alt-F1 session) up so I can choose which errant
> process to kill and pre-empt oom's choice?

You would need to adjust getty's score to -1000.
With legacy cgroupv1 there was a file to trigger OOMKiller in specific
cgroup. I don't see equivalent for current cgroups, probably it happens
when memory limits are crossed.
You can run a daemon to preemptively kill processes causing OOM, one
of such daemons is https://github.com/facebookincubator/oomd

-- 
Tomasz Torcz                “Funeral in the morning, IDE hacking
tomek@???         in the afternoon and evening.” - Alan Cox