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 к выпуску в ближайшие недели.
Собственно: 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
Сравним два сценария:
На первый вздляд скрипты одинаковы: в самом начале запускается бесконечный цикл, и интерпретация никогда не продолжится дальше.
Однако:
Первый скрипт при запуске потребляет 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/rfjakob/earlyoom#changelog
Пакет будет включен по умолчанию в Fedora 32 Workstation.
Основные изменения в выпусках:
1.5:
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 с отключенным оверкоммитом, или принципиально иначе?
oomd - обработчик нехватки памяти для датацентров, разрабатываемый Facebook.
Основные изменения в версии 0.3.0 - это улучшение производительности и несколько новых плагинов. Проверьте журнал фиксации для всего, что вошло начиная с выпуска 0.2.0. https://github.com/facebookincubator/oomd/releases/tag/v0.3.0
Есть ли возможность помещать дочерние процессы юнита в отдельный юнит, для котрого можно прописать отдельные правила и значения ключей? Как это реализовать в юните? Напимаер: созавать /system.slice/foo.slice/foo.service, а дочерние от foo процессы помещать в /system.slice/foo.slice/foo-children.scope. Как такое делается?
Про помещение всех в /system.slice/foo.slice понятно - просто пописываем в юните главного процесса Slice=system.slice/foo.slice. Возможно ли сделать так, чтобы дочерние процессы этого сервиса автоматически перекладывались в отдельный scope, чтобы применять к ним отдельные настройки для более тонкого контроля? 
intelfx
После 6 месяцев обсуждения родили предложение: https://fedoraproject.org/wiki/Changes/EnableEarlyoom.
Здесь можете высказать ваши мысли и чувства по этому поводу.
История вопроса: https://pagure.io/fedora-workstation/issue/98.
Летом был тред о неспособности ядра обрабатывать нехватку памяти: Линукс ядро не может мягко обрабатывать ситуации с нехваткой памяти
Пришло время продемонстрировать элегантное решение: https://youtu.be/G0FYDIKVPYI
Проблема: https://lkml.org/lkml/2019/8/4/15.
Решение: https://github.com/hakavlad/nohang.
Обсуждение в r/linux: https://www.reddit.com/r/linux/comments/ee6szk/killing_the_elephant_in_the_room_the_userspace/.
| ← предыдущие | следующие → |