Эта статья призвана познакомить читателя с находящимся в арсенале systemd набором инструментов.
Когда наконец удается смириться с уходом systemd от тех принципов, что лежали в основе ветхозаветной System V с ее простыми текстовыми файлами и засильем скриптов, начинаешь видеть неоспоримые преимущества новой системы инициализации и поставляемых с ней инструментов. В этой статье мы поговорим о четырех из них, а также упомянем еще один, который вы наверняка уже знаете, но вряд ли использовали описанным здесь способом.
Итак, начнем!
coredumpctl
Этот инструмент, как услужливо подсказывает его имя, используется для получения дампов памяти из журнала systemd.
Команда coredumpctl вернет общий список всех дампов памяти, в котором могут быть записи за несколько недель, а то и месяцев работы системы.
Рис. 1. coredumpctl выводит список всех дампов памяти, зарегистрированных в журнале
Выполнив coredumpctl dump filter, можно получить более подробную информацию о последнем подходящем под фильтр дампе:
coredumpctl dump 1758
Эта команда выведет все детали последнего дампа с PID 1758. А поскольку журнал systemd охватывает более одной сессии (мой, например, начинается с мая), в нем могут оказаться несколько не связанных друг с другом дампов от процессов с одинаковым PID.
Рис. 2. Модификатор dump позволяет получить более подробную информацию о дампе памяти
Также есть возможность установить фильтр по имени исполняемого файла:
coredumpctl dump chrome
Как и в случае с PID, эта команда выведет информацию только о последнем дампе, поскольку в большинстве случаев нужен именно он.
В фильтре дампа памяти может использоваться PID, имя исполняемого файла, путь, который должен содержать как минимум одну косую черту (например, /usr/bin/name_of_executable), а также один или несколько общих предикатов (general predicates) journalctl. Последний вариант показан в следующем примере:
coredumpctl dump _PID=1758
Эта команда по сути идентична coredumpctl dump 1758.
А вот более интересный пример использования предикатов journalctl, где нас интересует timestamp:
coredumpctl dump _SOURCE_REALTIME_TIMESTAMP=1463932674907840
Список предикатов journalctl можно найти в разделе JOURNAL FIELDS файла документации man systemd.directives.
Помимо dump у сoredumpctl есть и другие опции. Для тех, кто хочет сразу начать отладку, следующая команда не только выведет всю информацию о дампе, но и откроет GNU debugger (gdb):
coredumpctl gdb 1758
bootctl
А вы знаете, что загрузкой теперь управляет systemd-boot, а не GRUB? Да, это очередная функция, которую подмял под себя, кажется, уже не способный остановиться systemd. Правда, это пока касается только систем с UEFI.
Обучение настройке загрузчика выходит за рамки данной статьи (если вам действительно интересно, найти полезную информацию можно здесь), однако для установки пользовательской конфигурации загрузки необходимы хотя бы базовые знания bootctl.
(Если вы новичок в Linux, не пугайтесь. Вам, скорее всего, не придется делать ничего из представленного в данном разделе. Об этом позаботится ваш дистрибутив. Все, что здесь написано, в первую очередь предназначено для энтузиастов абсолютного контроля (например, пользователей Arch Linux). Эти люди не могут спать спокойно, пока в их системе остался хотя бы один параметр, который они не пробовали подкрутить.)
Для работы с bootctl нужны права суперпользователя, поэтому обращаться с этим инструментом нужно уважительно. Одно неосторожное движение — и ваша система перестанет загружаться.
Один из самых безобидных режимов bootctl — проверка статуса загрузки. Если /boot не указывает на раздел FAT EFI напрямую, нужно вручную с помощью опции —path= указать путь к загрузочному разделу EFI. Вот как выглядит команда для моей openSUSE:
bootctl --path=/boot/efi
Результатом будет список всех опций загрузки и соответствующих им переменных. Рисунок 3 показывает вывод команды на моей системе. Это поведение по умолчанию. Полная версия команды выглядит так: bootctl --path=/boot/efi status.
Рис. 3. Инструмент bootctl позволяет просматривать и изменять настройки программы управления загрузкой
В выводе команды можно найти опции загрузки и расположение бинарного файла загрузчика (ESP).
Измененная конфигурация загрузки устанавливается с помощью команды:
bootctl --path=/boot/path/to/efi install
Эта команда также сгенерирует бинарный файл systemd-boot, сохранит его в boot/path/to/efi/EFI/Boot и добавит соответствующий вызов в верхнюю часть списка приоритета загрузки.
Чтобы обновить systemd-boot, выполните:
bootctl --path=/boot/path/to/efi update
Для удаления systemd-boot из раздела EFI используйте:
bootctl --path=/boot/path/to/efi remove
Будьте осторожны с последней командой.
systemd-cgtop, systemctl и systemd-cgls
Если классический top позволяет найти процессы, больше других нагружающие CPU и активнее потребляющие память, systemd-cgtop делает то же самое для контрольных групп (cgroups).
Cgroups представляет из себя механизм разбиения и изолирования ресурсов системы для предоставления их группам пользователей и задач. Например, вы можете применить cgroups для установки ограничений на потребление памяти и CPU в системе, где работают две группы пользователей. Полное описание cgroups с примерами можно найти здесь.
systemd использует cgroups для контроля своих служб, а systemd-cgtop позволяет убедиться, что все группы ведут себя прилично. Если кто-то все-таки начал безобразничать, можно одним махом завершить работу сразу всей группы, а не разыскивать и останавливать каждый процесс в отдельности.
Взгляните на рисунок 4, где изображен пример нормально работающей системы. Никто не злоупотребляет ресурсами, и числового обозначения в строке с итогами удостоились только общие показатели активности всех групп системы. При этом я мог бы избавиться, например, от auditd, веди он себя неподобающим образом. И поскольку система без этого сервиса не остановится, так и сделаю:
systemctl kill auditd.service
И… та-дам! Его больше нет!
Рис. 4 systemd-cgtop сообщает о поведении cgroups
В данном случае у auditd.service были две связанные с ним задачи, но их могут быть сотни, особенно у групп, используемых для конечных пользователей, поэтому systemctl очень удобен для работы с cgroups.
Кстати, чтобы посмотреть, какие процессы связаны с той или иной cgroup, попробуйте команду systemd-cgls /cgroup.name
Например:
systemd-cgls /system.slice/NetworkManager.service
И вы увидите все процессы, работающие в подгруппе NetworkManager.
Заключение
Мы рассмотрели лишь малую часть предназначенных для системного администрирования инструментов systemd. Их, конечно, намного больше, и в следующей статье мы поговорим еще о нескольких. Также стоит помнить, что настоящая сила многих инструментов скрыта в их многочисленных опциях.
Если вы хотите получше разобраться в вопросах, связанных с systemd, рекомендую начать с идущей в комплекте документации:
man systemd.index
ссылка на оригинал статьи https://habrahabr.ru/post/315706/
Добавить комментарий