Earlyoom как запустить в ubuntu

Обновлено: 07.07.2024

earlyoom - The Early OOM Daemon

The oom-killer generally has a bad reputation among Linux users. This may be part of the reason Linux invokes it only when it has absolutely no other choice. It will swap out the desktop environment, drop the whole page cache and empty every buffer before it will ultimately kill a process. At least that's what I think that it will do. I have yet to be patient enough to wait for it, sitting in front of an unresponsive system.

As it turns out, no, it can't. At least using the in-kernel oom-killer. In the user space, however, we can do whatever we want.

What does it do

earlyoom checks the amount of available memory and free swap up to 10 times a second (less often if there is a lot of free memory). By default if both are below 10%, it will kill the largest process (highest oom_score ). The percentage value is configurable via command line arguments.

In the free -m output below, the available memory is 2170 MiB and the free swap is 231 MiB.

Why is "available" memory checked as opposed to "free" memory? On a healthy Linux system, "free" memory is supposed to be close to zero, because Linux uses all available physical memory to cache disk access. These caches can be dropped any time the memory is needed for something else.

The "available" memory accounts for that. It sums up all memory that is unused or can be freed immediately.

Note that you need a recent version of free and Linux kernel 3.14+ to see the "available" column. If you have a recent kernel, but an old version of free , you can get the value from grep MemAvailable /proc/meminfo .

When both your available memory and free swap drop below 10% of the total, it will send the SIGTERM signal to the process that uses the most memory in the opinion of the kernel ( /proc/*/oom_score ). It can optionally ( -i option) ignore any positive adjustments set in /proc/*/oom_score_adj to protect innocent victims (see below).

    , a similar project like earlyoom, written in Python and with additional features and configuration options.
  • facebooks's pressure stall information (psi) kernel patches and the accompanying oomd userspace helper. The patches are merged in Linux 4.20.

Why not trigger the kernel oom killer?

Earlyoom does not use echo f > /proc/sysrq-trigger because the Chrome people made their browser (and all electron-based apps - vscode, skype, discord etc) always be the first (innocent!) victim by setting oom_score_adj very high. Instead, earlyoom finds out itself by reading through /proc/*/status (actually /proc/*/statm , which contains the same information but is easier to parse programmatically).

Additionally, in recent kernels (tested on 4.0.5), triggering the kernel oom killer manually may not work at all. That is, it may only free some graphics memory (that will be allocated immediately again) and not actually kill any process. Here you can see how this looks like on my machine (Intel integrated graphics).

How much memory does earlyoom use?

About 2 MiB ( VmRSS ), though only 220 kiB is private memory ( RssAnon ). The rest is the libc library ( RssFile ) that is shared with other processes. All memory is locked using mlockall() to make sure earlyoom does not slow down in low memory situations.

Download and compile

Compiling yourself is easy:

Optional: Run the integrated self-tests:

Start earlyoom automatically by registering it as a service:

Note that for systems with SELinux disabled (Ubuntu 19.04, Debian 9 . ) chcon warnings reporting failure to set the context can be safely ignored.

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

For Fedora and RHEL 8 with EPEL, there's a Fedora package:

For Arch Linux, there's an Arch Linux package:

Availability in other distributions: see repology page.

Just start the executable you have just compiled:

It will inform you how much memory and swap you have, what the minimum is, how much memory is available and how much swap is free.

If the values drop below the minimum, processes are killed until it is above the minimum again. Every action is logged to stderr. If you are running earlyoom as a systemd service, you can view the last 10 lines using

In order to see earlyoom in action, create/simulate a memory leak and let earlyoom do what it does:

If you need any further actions after a process is killed by earlyoom (such as sending emails), you can parse the logs by:

Example output for above test command ( tail /dev/zero ) will look like:

For older versions of earlyoom , use:

Since version 1.6, earlyoom can send notifications about killed processes via the system d-bus. Pass -n to enable them.

To actually see the notifications in your GUI session, you need to have systembus-notify running as your user.

Additionally, earlyoom can execute a script for each process killed, providing information about the process via the EARLYOOM_PID , EARLYOOM_UID and EARLYOOM_NAME environment variables. Pass -N /path/to/script to enable.

Warning: In case of dryrun mode, the script will be executed in rapid succession, ensure you have some sort of rate-limit implemented.

The command-line flag --prefer specifies processes to prefer killing; likewise, --avoid specifies processes to avoid killing. The list of processes is specified by a regex expression. For instance, to avoid having foo and bar be killed:

The regex is matched against the basename of the process as shown in /proc/PID/comm .

If you are running earlyoom as a system service (through systemd or init.d), you can adjust its configuration via the file provided in /etc/default/earlyoom . The file already contains some examples in the comments, which you can use to build your own set of configuration based on the supported command line options, for example:

After adjusting the file, simply restart the service to apply the changes. For example, for systemd:

Please note that this configuration file has no effect on earlyoom instances outside of systemd/init.d.

Command line options

See the man page for details.

Bug reports and pull requests are welcome via github. In particular, I am glad to accept

  • Make victim selection logic 50% faster by lazy-loading process attributes
  • Log the user id uid of killed processes in addition to pid and name
  • Color debug log in light grey
  • Code clean-up
    • Use block-local variables where possible
    • Introduce PATH_LEN to replace several hardcoded buffer lengths
    • Add --prefer and --avoid options (@TomJohnZ)
    • Add support for GUI notifications, add options -n and -N

    v0.12: Add -M and -S options (@nailgun); add man page, parameterize Makefile (@yangfl)

    v0.11: Fix undefined behavoir in get_entry_fatal (missing return, commit)

    v0.10: Allow to override Makefile's VERSION variable to make packaging easier, add -v command-line option

    v0.9: If oom_score of all processes is 0, use VmRss to find a victim

    v0.8: Use a guesstimate if the kernel does not provide MemAvailable

    v0.7: Select victim by oom_score instead of VmRSS, add options -i and -d

    v0.6: Add command-line options -m , -s , -k

    v0.5: Add swap support

    v0.4: Add SysV init script (thanks @joeytwiddle), use the new MemAvailable from /proc/meminfo (needs Linux 3.14+, commit)

    Если вы работаете с «тяжелыми» приложениями в условиях нехватки оперативной памяти, вам знакома такая ситуация, как OOM — Out Of Memory, это когда запущенным программам нужно больше оперативной памяти, чем имеется в системе. В такой ситуации система обычно начинает свапиться на диск и при этом тормозить, что неприятно для пользователя.

    Механизм OOM Killer призван спасать системы на базе Linux от нехватки памяти. Работает он достаточно просто: когда память заканчивается он на основе специального алгоритма вычисляет процесс, смерть которого причинит меньше всего вреда и даст больше всего сободной памяти и убивает его.

    Установка и настройка

    На базе Red Hat (Fedora, Red Hat Linux Enterprise)

    sudo dnf install earlyoom

    На базе Arch Linux (Manjaro, Arch)

    sudo pacman -S earlyoom

    Для дистрибутива Ubuntu и ему подобных:

    В Ubuntu 18.04 Early OOM Daemon присутсвует в стандартном репозитории и его можно установить командой:

    Early OOM Daemon не имеет файла настроек и желаемые опции ему надо передавать в виде параметров командой строки. Описать их можно в файле «/etc/default/earlyoom». В этом файле есть некоторое количество примеров, достаточных для базовой настройки. Кроме того достаточно информативна man-страница сервиса. Прежде чем написать свою конфигурацию рассмотрим основные параметры:

    Здесь есть интересный момент: параметр -N расчитан на работу совместно с утилитой notify-send из пакета «libnotify-bin» и запускает команду примерно так:

    И отсюда начинаются проблемы: так как сам сервис работает от пользователя root и не имеет доступа к пользовательской сессии то необходимо придумать какой-то обходной манёвр. Автор этих строк тестировал earlyroom на дистрибутиве Lubuntu 18.04, работая под учётной записью с именем «moose» и в итоге был написал скрипт «/home/moose/scripts/earlyoom-notify.sh» следующего содержания:

    Этот скрипт по сути является обёрткой для notify-send и просто запускает notify-send в нужном окружении.

    В файле «/etc/default/earlyoom» конфигурация была описана следующим образом:

    Разумеется после изменения этих настроек необходимо перезапустить сервис командой:

    Проверка работы

    Узнать статус процесса Earlyoom можно с помощью следующей команды:

    Если в статусе указано «Active: active (running)» — всё в порядке, Earlyoom запущен и правильно работает. Теперь можно устроить в системе катастрофическую нехватку оперативной памяти для проверки работы Earlyoom. Для этого прежде всего отключим swap на диске, если таковой имеется, чтобы не ждать пока он заполнится.

    Ну а теперь забиваем всю доступную в системе оперативную память нулями:

    Далее должно произойте следующее: процесс tail должен занять всю доступную ОЗУ в системе, после чего его должен прибить Earlyoom, тем самым освободив оперативную память. Если у вас произошло именно так — поздравляю, всё работает как и должно! Успехов!

    Mechanism called OOM Killer to rescue the system based on the Linux from the memory. It works quite simple: when the memory ends it is based on a special algorithm calculates the process of death which will cause the least harm and provide the most slobodnoj memory and kills him.

    Installation and configuration

    On the basis of Red Hat (Fedora, Red Hat Enterprise Linux)

    sudo dnf install earlyoom

    sudo systemctl enable —now earlyoom

    On the basis of Arch Linux (Manjaro, Arch)

    sudo pacman -S earlyoom

    sudo systemctl enable —now earlyoom

    For Ubuntu and similar:

    Ubuntu 18.04 Early OOM Daemon is present in the default repositories and can be installed with:

    This script is essentially a wrapper for notify-send and runs notify-send in the right environment.

    Of course, after changing these settings, you must restart the service with the command:

    In the described configuration, the cleaning is triggered when memory remains less than 5% free RAM and less than 60% of the space on the swap. The first targets are the browser and mail client, and the last system services. When the application is closed is displayed in the corner of the screen.

    Check the operation of the

    To know the status of the process Earlyoom you can use the following command:

    And now the entire score is available in the system memory with zeroes:

    Further, should experience an abnormal the following: process tail must occupy the entire available RAM on the system, after which it needs to nail Earlyoom, thus freeing the RAM. If you have happened that way — congratulations, everything works as it should! Success!

    WARNING! All links in the articles may lead to malicious sites or contain viruses. Follow them at your own risk. Those who purposely visit the article know what they are doing. Do not click on everything thoughtlessly.

    • Open with Desktop
    • View raw
    • Copy raw contents Copy raw contents Loading

    Copy raw contents

    Copy raw contents

    earlyoom - The Early OOM Daemon

    The oom-killer generally has a bad reputation among Linux users. This may be part of the reason Linux invokes it only when it has absolutely no other choice. It will swap out the desktop environment, drop the whole page cache and empty every buffer before it will ultimately kill a process. At least that's what I think that it will do. I have yet to be patient enough to wait for it, sitting in front of an unresponsive system.

    As it turns out, no, it can't. At least using the in-kernel oom-killer. In the user space, however, we can do whatever we want.

    What does it do

    earlyoom checks the amount of available memory and free swap up to 10 times a second (less often if there is a lot of free memory). By default if both are below 10%, it will kill the largest process (highest oom_score ). The percentage value is configurable via command line arguments.

    In the free -m output below, the available memory is 2170 MiB and the free swap is 231 MiB.

    Why is "available" memory checked as opposed to "free" memory? On a healthy Linux system, "free" memory is supposed to be close to zero, because Linux uses all available physical memory to cache disk access. These caches can be dropped any time the memory is needed for something else.

    The "available" memory accounts for that. It sums up all memory that is unused or can be freed immediately.

    Note that you need a recent version of free and Linux kernel 3.14+ to see the "available" column. If you have a recent kernel, but an old version of free , you can get the value from grep MemAvailable /proc/meminfo .

    When both your available memory and free swap drop below 10% of the total, it will send the SIGTERM signal to the process that uses the most memory in the opinion of the kernel ( /proc/*/oom_score ). It can optionally ( -i option) ignore any positive adjustments set in /proc/*/oom_score_adj to protect innocent victims (see below).

      , a similar project like earlyoom, written in Python and with additional features and configuration options.
    • facebooks's pressure stall information (psi) kernel patches and the accompanying oomd userspace helper. The patches are merged in Linux 4.20.

    Why not trigger the kernel oom killer?

    Earlyoom does not use echo f > /proc/sysrq-trigger because the Chrome people made their browser (and all electron-based apps - vscode, skype, discord etc) always be the first (innocent!) victim by setting oom_score_adj very high. Instead, earlyoom finds out itself by reading through /proc/*/status (actually /proc/*/statm , which contains the same information but is easier to parse programmatically).

    Additionally, in recent kernels (tested on 4.0.5), triggering the kernel oom killer manually may not work at all. That is, it may only free some graphics memory (that will be allocated immediately again) and not actually kill any process. Here you can see how this looks like on my machine (Intel integrated graphics).

    How much memory does earlyoom use?

    About 2 MiB ( VmRSS ), though only 220 kiB is private memory ( RssAnon ). The rest is the libc library ( RssFile ) that is shared with other processes. All memory is locked using mlockall() to make sure earlyoom does not slow down in low memory situations.

    Download and compile

    Compiling yourself is easy:

    Optional: Run the integrated self-tests:

    Start earlyoom automatically by registering it as a service:

    Note that for systems with SELinux disabled (Ubuntu 19.04, Debian 9 . ) chcon warnings reporting failure to set the context can be safely ignored.

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

    For Fedora and RHEL 8 with EPEL, there's a Fedora package:

    For Arch Linux, there's an Arch Linux package:

    Availability in other distributions: see repology page.

    Just start the executable you have just compiled:

    It will inform you how much memory and swap you have, what the minimum is, how much memory is available and how much swap is free.

    If the values drop below the minimum, processes are killed until it is above the minimum again. Every action is logged to stderr. If you are running earlyoom as a systemd service, you can view the last 10 lines using

    In order to see earlyoom in action, create/simulate a memory leak and let earlyoom do what it does:

    If you need any further actions after a process is killed by earlyoom (such as sending emails), you can parse the logs by:

    Example output for above test command ( tail /dev/zero ) will look like:

    For older versions of earlyoom , use:

    Since version 1.6, earlyoom can send notifications about killed processes via the system d-bus. Pass -n to enable them.

    To actually see the notifications in your GUI session, you need to have systembus-notify running as your user.

    Additionally, earlyoom can execute a script for each process killed, providing information about the process via the EARLYOOM_PID , EARLYOOM_UID and EARLYOOM_NAME environment variables. Pass -N /path/to/script to enable.

    Warning: In case of dryrun mode, the script will be executed in rapid succession, ensure you have some sort of rate-limit implemented.

    The command-line flag --prefer specifies processes to prefer killing; likewise, --avoid specifies processes to avoid killing. The list of processes is specified by a regex expression. For instance, to avoid having foo and bar be killed:

    The regex is matched against the basename of the process as shown in /proc/PID/comm .

    If you are running earlyoom as a system service (through systemd or init.d), you can adjust its configuration via the file provided in /etc/default/earlyoom . The file already contains some examples in the comments, which you can use to build your own set of configuration based on the supported command line options, for example:

    After adjusting the file, simply restart the service to apply the changes. For example, for systemd:

    Please note that this configuration file has no effect on earlyoom instances outside of systemd/init.d.

    Command line options

    See the man page for details.

    Bug reports and pull requests are welcome via github. In particular, I am glad to accept