основатель сайхаб у светова. Скоро начало стрима

https://www.youtube.com/watch?v=nG_I2QQc9Ww

Во-первых, вышла новая линейка для этой самой защиты: https://github.com/hakavlad/le9-patch/tree/main/le9db_patches.

В описании патчей все написано.

Спрашивайте ответы, если еще остались вопросы.

Собственно сабж. systemd-oomd может убивать только целые контрольые группы.

В сессиях Xfce, Mate, LXDE etc. приложения и сессия лежат в общей группе session-X.scope.

При переполнении свопа сессия будет убиваться практически всегда и целиком.

https://bugzilla.redhat.com/show_bug.cgi?id=1933494

И похоже, что псем пофиг: юзеры все стерпят. Проблемы маргинальных DE никого не волнуют.

Ко всему прочему этот systemd-oomd грузит проц: в моем опыте в среднем на 0.6%.

Оправдывайтесь, alpha

Еще:

https://bugzilla.redhat.com/show_bug.cgi?id=1941340

https://bugzilla.redhat.com/show_bug.cgi?id=1941170

Debian 9, Linux 4.9. Внезапно гуй перестал отвечать, курсор мертв много минут. Почему такое происходит в 2020? Почему из коробки дистибутивы не научились лечить такое?

Фото стола: https://i.ibb.co/8MzTJzq/P-20201129-072410.png

WTF https://ibb.co/9N2c0pH https://ibb.co/xfD6Ty9 oom_score=666

При околонулевой памяти у большинства процессов, ядро последнее на f33 Linux 5.9.8, oom_score=666.

Может переваливать за тысячу https://ibb.co/f9mYsDC oom_score=1216

Когда начнет регулярно публиковаться сабж?

Фирма, занимающаяся безопасностью, Kaspersky заявила сегодня, что обнаружила версию вымогателя RansomEXX для Linux, что стало первым случаем, когда крупный штамм вымогателя Windows был перенесен на Linux для помощи в целевых вторжениях.

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

Программа-вымогатель использовалась в атаках на Министерство транспорта Техаса, Konica Minolta, подрядчика правительства США Tyler Technologies, систему общественного транспорта Монреаля и, совсем недавно, на судебную систему Бразилии (STJ).

RansomEXX - это то, что исследователи безопасности называют «охотником на крупную дичь» или «программой-вымогателем, управляемой человеком». Эти два термина используются для описания групп программ-вымогателей, которые охотятся на крупные цели в поисках больших выплат, зная, что некоторые компании или правительственные учреждения не могут позволить себе оставаться в стороне, пока они восстанавливают свои системы.

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

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

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

Версия для Linux имеет смысл с точки зрения злоумышленника; всегда стремятся расширить и затронуть как можно больше базовой инфраструктуры, стремясь нанести ущерб компаниям и требуя более высоких выкупов.

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

И эта тенденция, похоже, уже началась. По данным компании по кибербезопасности Emsisoft, помимо RansomEXX, банда вымогателей Mespinoza (Pysa) также недавно разработала вариант Linux на основе своей первоначальной версии Windows.

Но программа-вымогатель Linux тоже не уникальна. В последние годы другие банды вымогателей также создали штаммы вымогателей для Linux, такие как группа Snatch. Однако эти группы были небольшими операциями, которые полагались на спам-кампании для заражения жертв, редко были успешными и не участвовали в целевых вторжениях, подобных нынешнему поколению групп программ-вымогателей, которые мы наблюдаем сегодня.

https://www.zdnet.com/article/linux-version-of-ransomexx-ransomware-discovered/

Основные изменения:

• btrfs по умолчанию на десктопных вариантах

• swap on zram по умолчанию

• systemd-resolved по умолчанию

• nano - редактор по умолчанию

• earlyoom включен в KDE редакции

• включение демона uresourced по умолчанию для резервации ресурсов сессии для активного пользователя, см https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS - это должно помочь обрабатывать ситуации нехватки памяти

Прочие мелочи, см https://fedoraproject.org/wiki/Releases/33/ChangeSet

Всего несколько часов назад слился [1] с systemd Git - новый компонент systemd-oomd, продвигаемый Facebook.

Systemd-oomd был разработан для улучшения поведения Linux, связанного с нехваткой памяти / давлением памяти, и основан на коде демона нехватки памяти Facebook, который был расширен для работы не только с серверами Linux, но и с настольными системами.

Демон systemd-oomd опрашивает контрольные группы с поддержкой OOMD для мониторинга и завершает работу в зависимости от нехватки памяти или использования подкачки. Поведение systemd-oomd можно настроить с помощью нового файла конфигурации oomd.conf. Этот демон будет уничтожать группы только в том случае, если EnableOomdKill установлен как явно не желающий убивать случайные процессы из-за использования памяти. Другие новые настройки включают параметры ManagedOOMSwap=, ManagedOOMMemoryPressure= и ManagedOOMMemoryPressureLimitPercent=. Команда oomctl используется для анализа состояния systemd-oomd.

Для первоначального выпуска systemd 247, в котором проходит премьера, systemd-oomd будет отключен по умолчанию и требует установки -Dmode=developer во время сборки для активации режима разработчика. По крайней мере, на данный момент это считается функцией предварительного просмотра и все еще дорабатывается, поэтому на данный момент не рекомендуется для производственных сред.

Слияние составляет чуть более трех тысяч строк нового кода.

Разработчики Systemd работают над подготовкой systemd 247 к выпуску в ближайшие недели.

1. https://github.com/systemd/systemd/commit/69c0807432fa4fbfbf507a53872664cd26715559

Еще фото: https://imgur.com/a/dGPCVJd

Старенький ноутбук 2 ядра 1.7 гига Lenovo G580. Своп на zram, disksize=2.6G.

Стренький Минт, уже несколько лет работает. Систему обновляю раз в несколько месяцев.

Основная задача: беспроблемный веб-браузинг: ютуб, яндексы, погода, новости, местные сайты. Доступ к популярным сайтам обеспечивается браузерм c визуальными закладками.

Firefox с одним обработчиком контента для экономии потребления памяти.

Для обработки нехватки памяти используется, конечно, nohang (при обычном браузинге на самом деле до этого никогда не доходит, десятки вкладок можно без проблем открыть).

С веб-браузингом машина вполне справляется, zram помогает делать своппинг безболезненным.

На системном мониторе со старта занято 600М, с браузером с несколькими вкладками - 1G.

Все работает как часы, проблем никаких не было. Батя доволен. Единственный случай был: установщики роутера из Ростелекома предлагали снести эту непонятную систему и установить вместо этого нормальную винду.

>>> Просмотр (1366x768, 788 Kb)

Собственно: https://youtu.be/fPnbnNX9CPE

Система на HDD, Debian 9 Mate, MemTotal=10GB, swap on zram (disksize=14GB). memavaild, prelockd и nohang-desktop работают в фоне и помогают сохранять отзывчивость несмотря ни на что.

https://github.com/hakavlad/nohang

https://github.com/hakavlad/prelockd

https://github.com/hakavlad/memavaild

Кратко: prelockd - новейшее оружие в борьбе за отзывчивость при нехватке памяти.

Спрашивайте ответы.

python3.9.0rc1, Fedora 33

Сравним два сценария:

1. https://github.com/hakavlad/nohang-extra/blob/master/NOH_39_FAT/2/1
2. https://github.com/hakavlad/nohang-extra/blob/master/NOH_39_FAT/2/2

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

Однако:

Первый скрипт при запуске потребляет 11924 кб анонимной памяти (VmRSS: 16 MiB).

Второй - 3856 кб анонимной (VmRSS: 8 MiB).

В чем подвох? С более старыми версиями проблемы не было. С новым интерпретатором - аномально высокое потребление анонимной памяти. Каково возможное объяснение явления? Само рассосётся или репортить?

Физики Швейцарской высшей технической школы Цюриха (самого престижного вуза Швейцарии) выбирают nohang для обработки нехватки памяти на своих рабочих станциях:

OOM долгое время был проблемой, к счастью, пакет nohang с бэкпортированием для 18.04 и 20.04 очень помогает. Имейте в виду, что с 20.04 он работает намного лучше из-за более нового ядра и поддержки PSI.

https://readme.phys.ethz.ch/linux/software_on_the_d-phys_linux_computers/

Скоро выйдет systemd 246, похоже, что вскоре после этого новый демон нехватки памяти будет объединен, что даст достаточно времени для тестирования перед systemd 247.

Systemd-oomd - это демон нехватки памяти, разработанный Facebook и разработчиками systemd. Они стремятся к тому, чтобы Linux лучше справлялся с ситуациями нехватки памяти / нехватки памяти. Facebook изначально написал свой код OOMD для своих серверов и с тех пор продолжает дорабатывать и адаптировать, чтобы он одинаково хорошо работал и на настольных компьютерах, и не только.

Systemd-oomd опрашивает systemd на наличие контрольных групп с поддержкой OOMD, чтобы отслеживать их и уничтожать в зависимости от нагрузки на память или использования подкачки. Поведение systemd-oomd контролируется с помощью нового файла конфигурации oomd.conf. Cgroups должен будет использовать EnableOomdKill, если они хотят быть убитыми, когда находятся под давлением.

Возвращаясь к марту, вы получили запрос 15206 с незавершенным кодом systemd-oomd. Недавно произошел всплеск изменений в коде.

http://www.phoronix.com/scan.php?page=news_item&px=systemd-oomd-coming-soon

в убунту 20.04 юзер может успешно выполнять mlockall() без рута. Как вам такое?

psi-notify может предупредить вас, когда в системе появится конкуренция за ресурсы (cpu, memory, io), и позволит вам предпринять действия, прежде чем ваша система замедлится.

psi-notify - это минимальный непривилегированный уведомитель для нехватки ресурсов в масштабе всей системы с использованием PSI. Это может помочь вам идентифицировать неправильно работающие приложения на вашем компьютере до того, как они начнут серьезно влиять на быстродействие системы, в отличие от MemAvailable, графиков ЦП, графиков использования ввода-вывода и других показателей.

psi-notify использует libnotify для отправки уведомлений на рабочий стол при нехватке ресурсов.

https://github.com/cdown/psi-notify

Изменения: https://github.com/rfjakob/earlyoom#changelog

Пакет будет включен по умолчанию в Fedora 32 Workstation.

Основные изменения в выпусках:

1.5:

• демон темерь запускается не от рута в системх c systemd. Следствие: сломались гуи уведомления у тех, у кого были они включены.
• разрешено одновременное указание опций -m и -M для определения порога памяти, после которого будет коррекция. Используется меньшее значение из двух.

1.6:

• новый механизм уведомлений, старый сломался. Теперь так: нужно запускать демона с опцией -n, а в сессии юзера должен быть запущен свежевыпущенный демон systembus-notify, который нигде не опакечен.

Эксперты по опакечиванию тут? Как при опакечивании deb пометить файл конфига, что не нужно его изменять при будущих обновлениях?

В rmp в спеках это делается так:

%config(noreplace) %{_sysconfdir}/%{name}/%{name}foo.conf

В арче:

backup=(
	'etc/foo/foo.conf'
)

Как в дебиане?

Лень писать новость, держите лог: https://github.com/rfjakob/earlyoom#changelog

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

Между прочим, earlyoom уже включен по умолчанию в Fedora 32 Workstation для тестирования на ничего не подозревающих юзерах.

Расскажите, пожалуйста, отличается ли обработка нехватки памяти в *BSD от обработки нехватки памяти в Linux при отключении оверкоммита? Как именно *BSD обрабатывает нехватку памяти? Как Linux с отключенным оверкоммитом, или принципиально иначе?