It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.
Install oomd or earlyoom.
Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
61–70 of 103 posts
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#62It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.
Or to kill anything at all in this lifetime.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#63It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.
You can use `earlyoom --prefer firefox --avoid xlock`.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#64I confess, this is very funny and the underlying situation is a bit absurd, but it's unclear what point Brouwer is making by pointing out the absurdity. There surely is something absurd about having to register specific processes as exempt from the OOM killer. But given that the OOM killer exists, and could kill xlock...how should that be fixed?
I read him as arguing that overcommit was a mistake. Of course, he doesn't answer any of the obvious follow-up questions, such as, does fork–exec copy all the process's memory and then immediately throw it away, or what. (One could argue that fork–exec was also a mistake, but it long predates Linux, so this doesn't answer the question of how Torvalds should have designed it.)
Fork should be replaced by vfork (or something better) in almost all situations.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#65Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#66Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#67Earlier quoted context omitted.
> does fork–exec copy all the process's memory NT: Yes? Why not? (note that this refers to the Windows NT kernel's operation because it had historically a POSIX emulation layer (NT Personalities), not the modern WSL which is just Linux in a Hyper-V)
because this is what causes Windows to use ~80% more memory than unixes
Well, in that case it's a good thing I guess. Windows is orders of magnitude better when it comes to memory management on the desktop compared to Linux. Like why would I even want a single process killed by OOM killer? On Windows things just work, or get slow. On Linux it works and then mayhem ensues.
Last year I was writing a reply on a forum in Firefox on Linux when the OOM killer decided to nuke Firefox. Poof gone, mid keystroke. How does anyone think that's acceptable?
This was on a stock Linux distro, nothing special.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#68It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.
It would be nice to have a signal as a warning to process to reduce it's memory footprint or else OOM will kill it.
Re: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#69I know this is not a popular / mainstream position, but I managed a very large fleet of systems this way: - no system swap - enough memory for core system services set aside in a cgroup for them to use - by default, all prod service binaries load all code pages into ram at start, and lock them in (no paging out code pages at runtime) - if needed (rare) services can mount some swap in their own cgroup, but very much d…
Have you disabled swap in the kconfig entirely? If not, is your vm.swapiness 0? How do you deal with overcommit? Did you replace malloc with a more strict implementation?
> How do you deal with overcommit
echo 2 > /proc/sys/vm/overcommit_memoryRe: Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
#70Earlier quoted context omitted.
IMO if the security of a system depends on the lock screen not crashing then the system is not very secure. Security protocols should never fail open like that; a lock screen should never simply be a layer on top of the authenticated desktop. Windows and macOS get this right. I believe Wayland display managers are also able to get this right (but I haven't checked).
Yes, Wayland should fix this. Granted, then you have a locked screen that the user may or may not be able to unlock, which is awkward if better.
Wayland the protocol already fixes this -- there's nothing that exactly requires a display manager to not have a completely separate desktop for the unauthenticated state, where a trusted application (or the display manager itself) can accept credentials in order to authorize a transition to the authenticated state, and where a crash of the trusted application or lock screen does not result in access to the authenticated state. I just dunno if anyone does that yet. I'm sure somebody must have...
> Granted, then you have a locked screen that the user may or may not be able to unlock, which is awkward if better.
The most secure system is one that cannot be accessed, technically. In some cases it's better not to let anybody in than to let an attacker in (technically). Of course, this is frustrating for the user.