При сборке chromium закрываются все открытые терминалы

Я могу только одно предположить: кушает много памяти, терминалы закрываются OOM Kill’ером. Проверить можно промониторив загрузку памяти в динамике.

У меня 64 Гб. куда ему ещё?

Блин а ты прав. Сейчас глянул и действительно на 35 минуте сборки, он прям резко начинает кушать память.

А что с этим делать можно?

Держаться подальше от блоатвари, в том числе той что гугл генерирует.

Ещё можно сделать zram + много свапа. Но первый совет это не отменяет.

Прикольно, конечно. Надо 128 GB ОЗУ для сборки получается? Или 256 GB, чтобы не каждый Вася смог собрать? Лол.

Во сколько потоков собираешь? ЕМНИП, gcc может использовать до 2 гигабайт на поток.

Сборка во сколько потоков? Если несколько, то уполовинь для начала.

Еще совсем недавно при сборке в 32 потока без раста, жрал всего лишь чуть больше 32Гб.
А какой именно компонент собирается в момент, когда 64Гб не хватает?

Дело в многопоточной сборке. В один поток вполне нормально и на 8 гигах собирать, только долго.

Если компилировать в виртуалке и настроить ей память, тогда точно не вылезет

Увеличить своп, вырубить дрянь, которая вырубает левые приложения - оом киллер должен был убить разожравшуюся сборку, если он убивает что-то другое значит он кривой.

Дай угадаю, ты из секты ненужности свопа?

Думаю что емерж запускался в терминале, сборка запускалась емержем, поэтому киллер терминалы и прибил. Вслед за этим должон помереть емерж, управляющий терминал потеряв, а затем и процессы сборки. Просто если их много они не моментально умирают после смерти емержа, и кажется что киллер не то убил.

ну вообще с 64 Гб он не нужен, это первый раз когда ему вдруг не хватило ОП.

Да, уже собирает норм. Добавил файл со свопом.

ну вообще с 64 Гб он не нужен, это первый раз когда ему вдруг не хватило ОП.

О, я угадал

-j32

Если честно не знаю, что такое «блоатвари».

Это софт, в котором всякой неорганизованной помойки кратно больше чем полезного кода.

В районе этих файлов:

/content/browser/devtools/network_service_devtools_observer.cc
../../content/browser/devtools/protocol/fedcm_handler.cc
../../content/browser/dom_storage/session_storage_namespace_impl.cc
../../content/browser/devtools/protocol/devtools_mhtml_helper.cc
../../content/browser/download/data_url_blob_reader.cc
../../content/browser/devtools/tracing_process_set_monitor.cc

Думаю что емерж запускался в терминале, сборка запускалась емержем, поэтому киллер терминалы и прибил.

Вероятно да, но прибить-то он должен был гцц. Т.е. оом киллер криво работает и это надо репортить.

Вероятно да, но прибить-то он должен был гцц. Т.е. оом киллер криво работает и это надо репортить.

Я так не думаю. А если предположим нечто будет постоянно перезапускать протекающий процесс, киллер так и будет без конца приходить что ли? Мне кажется вполне логичным что он докопался до первоначального управляющего расшалившимся безобразием терминала и убил его, убив тем самым всё что им порождалось. Только меня смущает что он все терминалы убил, а не только тот где емерж запущен. Возможно я не прав, я логику киллера не знаю тащемто.

Если это systemd-oomd, то он убивает все процессы в systemd slice, не сортируя на наших и ненаших.

Отсюда следствие: сборку надо запускать в отдельном слайсе.

Возможно. У него гента же, там может быть и systemd, и openrc... Надо бы почитать что такое systemd slice, это какая то неведомая мне инопланетная технология. cgroups знаю, slice не знаю...

При сборке андроида есть Heap Size и Heap Limit, что-то подобное везде есть

Если смотреть на дерево процессов на три окна терминала konsole в htop:

/sbin/init allow-discard
 |-/lib/systemd/systemd --user
   |-/usr/bin/plasmashell --no-respawn
     |-/usr/bin/konsole
       |-/usr/bin/konsole
       |-/usr/bin/konsole
       |-/bin/bash
         |-sudo htop
       |-/bin/bash
       |-/bin/bash
         |-mc
           |-bash -rcfile .bashrc

systemctl status говорит, что он не работает.

○ systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer
     Loaded: loaded (/lib/systemd/system/systemd-oomd.service; disabled; preset: disabled)
     Active: inactive (dead)
TriggeredBy: ○ systemd-oomd.socket
       Docs: man:systemd-oomd.service(8)
             man:org.freedesktop.oom1(5)

Стоит включить?

Уже «Решено» стоит, а не рано?

Да, тема называется «При сборке chromium закрываются все открытые терминалы». И ТС похоже что-то ‘подшаманил’ с oom-killer (systemd-oomd), решив озвученную проблему, теперь закрывается только терминал с компиляцией chromium. )

А как же «Компиляция chromium с какого-то перепугу выжирает все 64G памяти. Пошаговое исправление»? Нам тоже интересно. 🙂

Пошаговое исправление

Боюсь что чтобы это исправить, придется начинать очень изглубока - например, с пересмотра классической западной философии, породившей через века дегенератов.

Решением было создать своп файл и собрать chromium с ним.

Спасибо за ответ.

создать своп файл

Проверь еще, чтобы был включен zswap, это разгрузит i/o диска. У некоторых дистров (например, арч) он включен по умолчанию. И это современное решение, альтернатива старому методу просто со свопом.
https://wiki.gentoo.org/wiki/Zswap#Interactive_configuration.

upd. Еще одно современное решение, но на «Gentoo wiki» я не нашел ни одной статьи с упоминанием. )

$ cat /sys/kernel/mm/lru_gen/enabled
0x0007

докопался до первоначального управляющего расшалившимся безобразием

Тогда уж пид1 надо убивать - корень всех проблем.

он все терминалы убил

Так я о том и говорю, что он неправильно принял решение о том что прибить. Возможно он как хирург из анектода решил удалить легкое, потому, что печени места уже не хватало.

systemd-oomd наверняка не заработает, но можешь попробовать. Надо включить этот сервис и проверить вывод oomctl. На Федоре (где systemd-oomd по дефолту) он у меня показал много слайсов в Memory Pressure Monitored CGroups. Но на Сузе oomctl ничего не показал, и systemd-oomd там не заработал. А вот earlyoom зато прекрасно заработал.

Как проверять: tail /dev/zero

Собрать ядро без всяких low memory killer

А если у меня ssd на 120гб. То создание свопа сожрёт от половины до всего моего диска!