Библиотека сайта rus-linux.net
5 инструментов из состава systemd, которые следует начать использовать прямо сейчас
Оригинал: 5 systemd Tools You Should Start Using Now
Автор: Paul Brown
Дата публикации: 2 ноября 2016 г.
Перевод: А.Панин
Дата перевода: 2 декабря 2016 г.
В статье кратко описываются малоизвестные инструменты из комплекта поставки systemd, предназначенные для администрирования системы.
После того, как вы смиритесь с утратой текстовых сценариев SystemV, вам придется привыкать к новому, не менее функциональному инструментарию systemd. В рамках данной статьи мы рассмотрим четыре малоизвестных инструмента из состава systemd, а также один инструмент, с которым вы, скорее всего, уже знакомы, но не используете его таким образом, как будет показано ниже.
Что же, давайте приступим к делу без лишних пауз...
coredumpctl
Вы можете использовать данный инструмент для извлечения дампов памяти из журнала systemd (что вполне очевидно из его названия).
Если вы выполните команду
coredumpctl
вы получите список всех зарегистрированных в журнале systemd дампов памяти. В данном списке может содержаться информация даже о тех дампах памяти, которые были созданы несколько недель или несколько месяцев назад.
Рисунок 1. Утилита coredumpctl выводит список всех дампов памяти, зарегистрированнных в журнале systemd.
В случае исполнения команды
coredumpctl dump <критерий фильтрации>
вы получите более подробную информацию последнем дампе памяти, который соответствует заданному критерию фильтрации. Поэтому в результате исполнения команды
coredumpctl dump 1758
будет выведена подробная информация о последнем дампе памяти процесса с идентификатором (PID), равным 1758. Ввиду того, что журнал systemd используется в рамках более, чем одной сессии (к примеру, в моем случае в журнале содержатся данные о сессиях, имевших место в далеком мае), вполне вероятно, что в нем будет содержаться информация о нескольких не связанных друг с другом дампах памяти процессов с одним и тем же идентификатором.
Рисунок 2. Параметр dump позволяет получить гораздо больший объем информации об интересующем вас дампе памяти.
Аналогично, в том случае, если вы используете имя исполняемого файла в качестве критерия фильтрации, к примеру, следующим образом
coredumpctl dump chrome
вы получите информацию о последнем дампе памяти процесса chrome. Данная команда имеет смысл, так как вам наверняка понадобится осуществлять диагностику работы процесса с известным именем.
Вы можете осуществлять фильтрацию дампов памяти на основе идентификаторов процессов (как было показано выше), имен исполняемых файлов (также было показано выше), путей к исполняемым файлам (которые должны содержать как минимум один символ слэша и быть представлены, к примеру, в формате /usr/bin/<имя исполняемого файла>), а также одного или нескольких основных предикатов journalctl. В качестве примера последнего случая может выступать команда
coredumpctl dump _PID=1758
которая полностью аналогична рассмотренной выше команде coredumpctl dump 1758.
Другим, более интересным примером использования предикатов journalctl, является поиск дампов памяти по их меткам времени
coredumpctl dump _SOURCE_REALTIME_TIMESTAMP=1463932674907840
Для получения списка всех предикатов journalctl следует обратиться к разделу JOURNAL FIELDS страницы руководства systemd.directives.
Если вместо параметра dump будет использоваться параметр gdb также, как и в команде
coredumpctl gdb 1758
то помимо информации о дампе памяти вы получите доступ к отладчику проекта GNU (GNU debugger, gdb), который может использоваться для непосредственной отладки приложения.
bootctl
Если вы не следили за последними изменениями в экосистеме Linux, вам стоит знать, что за загрузку системы с недавнего времени отвечает не только системный загрузчик GRUB, но и программный компонент systemd-boot. Да-да, это так! Системный загрузчик GRUB - это еще один программный компонент, частично поглощенный systemd, по крайней мере, на современных машинах с прошивками UEFI.
Хотя полное описание процесса настройки системного загрузчика и выходит за рамки данной статьи (если вас интересует этот вопрос, вы можете обратиться к ), следует упомянуть о том, что при использовании его нестандартной конфигурации вам в любом случае придется воспользоваться утилитой bootctl для его установки.
(Если вы не имеете опыта работы с Linux, вам не стоит беспокоиться: вы наверняка никогда не столкнетесь с необходимостью выполнения действий, описанных в данной статье. Ваш дистрибутив выполнит их за вас. Она предназначена главным образом для людей, которые желают знать все о своей системе, таких, как пользователи дистрибутива Arch Linux.)
Вам придется использовать утилиту bootctl от лица пользователя root (или вызывать ее с помощью утилиты sudo). Это является первым признаком того, что вы должны относиться к данной утилите с особой осторожностью: ее некорректное использование может привести к невозможности загрузки системы, поэтому рекомендую быть максимально осторожным.
Безопасный способ использования утилиты bootctl заключается в ее использовании для проверки корректности процесса загрузки вашей системы. Обратите внимание на то, что в том случае, если раздел EFI с файловой системой FAT не смонтирована непосредственно в директорию /boot, вам придется указать путь к этому разделу самостоятельно с помощью аргумента --path=. В моей системе OpenSUSE, к примеру, мне приходится использовать команду
bootctl --path=/boot/efi
В результате исполнения данной команды будет выведен список параметров загрузки и значений используемых в процессе загрузки переменных. Вы можете увидеть ее вывод на моей системе на Рисунке 3. Это стандартный режим работы рассматриваемой утилиты, который также активируется в результате выполнения команды
bootctl --path=/boot/efi status
Рисунок 3. Инструмент bootctl позволяет просматривать и модифицировать параметры менеджера загрузки системы.
В данном выводе несложно обнаружить путь к загрузочному бинарному файлу (ESP:), а также значения всех параметров загрузки системы.
Если вы создали свой фреймворк для загрузки системы, вы можете установить его с помощью команды
bootctl --path=/boot/путь/к/разделу/efi install
Данная команда осуществляет автоматическую генерацию загрузочного бинарного файла systemd-boot, его сохранение по пути /boot/путь/к/разделу/efi/EFI/Boot и добавление соответствующей ему записи на вершину списка загрузки.
Если у вас в распоряжении имеется новая версия загрузочного бинарного файла, чем тот, что установлен в разделе EFI, вы можете обновить его с помощью команды
bootctl --path=/boot/путь/к/разделу/efi update
Для удаления загрузочного бинарного файла из раздела EFI достаточно воспользоваться командой
bootctl --path=/boot/путь/к/разделу/efi remove
Думаю, не стоит напоминать о том, что вы должны проявлять особую осторожность при работе с последней командой.
systemd-cgtop
По аналогии с классической утилитой top, которая выводит информацию о процессах, наиболее интенсивно использующих ресурсы вашей системы, утилита systemd-cgtop выводит информацию о группах контроля (cgroups), которые используют большую часть циклов центрального процессора и ячеек оперативной памяти вашего компьютера.
Если вы не знакомы с концепцией групп контроля, вам следует знать, что они в общем случае предназначены для разделения системных ресурсов между группами пользователей и задач. Вы можете использовать группы контроля, к примеру, для установки ограничений в плане использования ресурсов центрального процессора и памяти на машине, которая используется двумя группами пользователей со своими наборами приложений. Вас также может заинтересовать .
systemd активно использует группы контроля для управления состоянием своих служб, а с помощью утилиты systemd-cgtop вы можете в любой момент убедиться в том, что ни одна из групп контроля не вышла из-под вашего управления. В том же случае, если это произошло, вы можете уничтожить всю группу без необходимости поиска каждого из ее процессов с его последующим уничтожением.
Обратитесь к Рисунку 4. На этом рисунке приведена информация о группах контроля корректно работающей системы. Никакая из групп контроля не потребляет чрезмерное количество системных ресурсов, при этом регистрируется лишь минимальная активность процессов в группах. Но я могу, к примеру, завершить исполнение службы auditd в том случае, если она начнет работать некорректно. Так как данная служба не является необходимой для корректного функционирования системы, я могу выполнить эту операцию с помощью команды
systemctl kill auditd.service
И... все! Она исчезнет из списка групп контроля!
Рисунок 4. Утилита systemd-cgtop выводит информацию о текущем состоянии групп контроля.
В данном случае со службой auditd.service ассоциировано лишь два процесса, но вы без труда можете обнаружить группы контроля буквально с сотнями процессов, что актуально для групп контроля, используемых для нужд конечных пользователей, поэтому использование утилиты systemctl для управления группами контроля является достаточно удобным решением.
Кстати, если вам нужно ознакомиться со списком процессов в заданной группе контроля, вы можете воспользоваться командой
systemd-cgls /имя.группы
Например, вы можете выполнить аналогичную команду
systemd-cgls /system.slice/NetworkManager.service
В результате вы увидите список всех процессов из группы контроля службы NetworkManager.
Заключение
Это было всего лишь краткое описание нескольких инструментов из состава systemd, предназначенных для администрирования системы. К сожалению, мы не рассмотрели множество других инструментов (мы постараемся исправить это недоразумение в следующей статье), а также некоторые параметры и комбинации параметров описанных инструментов, позволяющие использовать их более эффективно, чем может показаться возможным на первый взгляд.
Если вы хотите более глубоко изучить возможности systemd, вы можете воспользоваться командой
man systemd.index
для получения доступа к списку всех страниц руководств, связанных с systemd.