Puppy Linux Discussion Forum

Linux has an Out Of memory killer (oom_klller)
Currently, The oom-killer does not seem to work, In Puppy and in other linux distros.

You can try to configure it so that it works better. Search the net for oom killer, oom_kill_allocating_task etc etc.

Or you can try earlyoom - Early OOM Daemon for Linux
https://github.com/rfjakob/earlyoom

For Debian 10+ and Ubuntu 18.04+, there's a Debian package

So I downloaded a precompiled 64 bit .deb from https://packages.debian.org/sid/amd64/earlyoom/download
i unzipped it, put it in /root/my-applications/bin/ ( /usr/bin/ would also work )
It's a single executable file, 34k.
I ran it in a text terminal (console) earlyoom -r 0 & disown
It seems to run properly.
It causes tail /dev/zero to be killed.
In BionicPuP64, anyway.

A good place to start it from automatically at boot might be /etc/rc.d/rc.local
Paste something like earlyoom -pr0 --avoid 'Xorg' --prefer 'firefox-bin' & disown into /etc/rc.d/rc.local

EDIT: Lately, I've been running earlyoom with these parameters (I have no swap):
earlyoom -r0 -m2 --avoid Xorg

It should kill the process using large amounts of ram, and prevent the operating system from crashing.
It uses about 200k of ram when running.

https://github.com/rfjakob/earlyoom
http://manpages.ubuntu.com/manpages/bio ... oom.1.html
https://pkgs.org/download/earlyoom
https://en.wikipedia.org/wiki/Out-of-memory

PPS This is what --prefer and --avoid match to: cat /proc/[0-9]*/stat | awk '{print $2}'

EDIT: attached earlyoom 1.6.2 64 bit pet, compiled in BionicPup64 8.0

It should kill the process using large amounts of ram, and prevent the operating system from crashing.

Just curious:

Why in the hell should anyone kill processes at the boot process of an operating system?

Usually there shouldn't be processes at boot using lots of RAM and therefor needs to be killed before entering the graphical DE!

File/script /etc/rc.d/rc.local is executed at boot.
Could be used to setup some stuff before booting into the graphical DE.

Earlyoom could be started after Xwindows starts, possibly from /root/Startup/

Earlyoom is not an Xwindows application, so it could start before Xwindows starts, and probably should,, so that killing X would not also kill earlyoom. If earlyoom is started when X starts, and it keeps running after X is killed or restarted, then when X restarts there might be 2 or more instances of earlyoom running. It's really better to start earlyoom before X starts.

/etc/rc.d/rc.local is a good place for it to start. Newer versions of Puppy can start applications from other places in /etc/ eg. /etc/init.d/, but /etc/rc.d/rc.local is the place to start cli applications that has been used by Puppy for many many years.

earlyoom runs in user space, but does what the kernel is supposed to do from when the kernel starts to when the kernel exits, when Puppy shuts down.

Why in the hell should anyone kill processes at the boot process of an operating system?

That is what the kerhel is supposed to be doing, starting from before the initrd starts executing. The consensus on the internet seems to be that the kernel's builtin OOM killer is not working properly, at least for now.

PS By the way, I have been starting earlyoom from a script after X starts. It would be necessary for me to remaster my adrv.sfs to change rc.local.

From a comparison of Fedora and Ubuntu https://www.maketecheasier.com/fedora-vs-ubuntu/

Both distros have excellent performance. However, there are two primary differences that help Fedora take the lead. The first is EarlyOOM, an early out-of-memory killer that’s baked into Fedora. To be brief, EarlyOOM is a much more aggressive out-of-memory killer than the one that’s in the Linux kernel and has a huge impact on low-memory systems and on systems that have memory-intensive applications. I recommend listening to this podcast episode from Linux Unplugged where they put EarlyOOM to the test.

earlyom podcast https://linuxunplugged.com/348

From https://ask.fedoraproject.org/t/how-do- ... a-33/10821

I’m sure these guidelines are great for servers, but for desktops we now recommend no swap partition or swap file. If you want to maintain system responsiveness, you need to let earlyoom kill processes that use too much memory before throttling begins, and earlyoom will not do that until swap is filled. So the larger you create your swap partition, the worse your throttling is going to be

I would think, in this case, a smaller than RAM swap would be better...say half of RAM.

Then best of both worlds are active for system stability.