П'ять інструментів systemd, які варто почати використовувати прямо зараз


Ця стаття покликана познайомити читача з перебувають в арсеналі 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

Creative Commons Zero
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.