author: Wale Soyinka contributors: Steven Spencer, Ganna Zhyrnova tested on: Всі версії tags: - лабораторні вправи - керування завантаженням - цільове управління - управління обслуговуванням - systemd - systemctl

Лабораторна робота 3: Процеси завантаження та запуску¶

Завдання¶

Після виконання цієї лабораторної роботи ви зможете:

вручну контролювати деякі процеси та служби запуску
автоматично керувати послугами

Приблизний час виконання цієї лабораторної роботи: 50 хвилин

Огляд процесу завантаження¶

Вправи в цій лабораторній роботі розпочнуться від процесу завантаження до входу користувача. Ці кроки перевірять і намагатимуться налаштувати частини процесів завантаження. Етапами високого рівня в процесі завантаження є:

Підсумок кроків¶

Апаратне забезпечення завантажує, читає та виконує завантажувальний сектор.
завантажувач виконується (GRUB у більшості дистрибутивів Linux)
ядро розпаковується та виконується.
ядро ініціалізує обладнання.
ядро монтує кореневу файлову систему.
ядро виконує /usr/lib/systemd/systemd як PID 1.
systemd запускає модулі, необхідні та налаштовані для запуску цільового завантаження за замовчуванням.
програми getty створюються на кожному визначеному терміналі.
getty запитує вхід.
getty виконує /bin/login для автентичного користувача.
вхід запускає оболонку.

`systemd`¶

systemd — це менеджер системи та послуг для операційних систем Linux.

Юніти `systemd`¶

systemd забезпечує систему залежності між різними сутностями, які називаються "одиницями". Модулі інкапсулюють різні об’єкти, необхідні для завантаження та обслуговування системи. Більшість одиниць налаштовуються у так званих файлах конфігурації одиниць — простих текстових файлах у стилі ini.

Типи юнітів `systemd`¶

У systemd визначено наступні 11 типів одиниць:

Service units запускають і контролюють демони та процеси, з яких вони складаються.

Socket units інкапсулюють локальні IPC або мережеві сокети в системі, корисні для активації на основі сокетів.

Target units використовуються для групування інших одиниць. Вони забезпечують добре відомі точки синхронізації під час завантаження

Device units розкриває пристрої ядра в systemd і може використовуватися для реалізації активації на основі пристрою.

Device units керують точками монтування у файловій системі

Automount units надають можливості автоматичного монтування для монтування файлових систем на вимогу, а також розпаралеленого завантаження.

Timer units корисні для ініціювання активації інших одиниць на основі таймерів.

Swap units дуже схожі на модулі монтування та інкапсулюють розділи або файли підкачки пам’яті операційної системи.

Path units можуть активувати інші служби, коли об’єкти файлової системи змінюються або модифікуються.

Slice units можна використовувати для групування одиниць, які керують системними процесами (таких як одиниці обслуговування та області) в ієрархічному дереві з метою керування ресурсами.

Scope units подібні до службових одиниць, але керують сторонніми процесами, а не запускають їх.

Завдання 1¶

/usr/lib/systemd/systemd | PID=1¶

Історично init називався багатьма іменами та мав кілька форм.

Незалежно від назви чи реалізації, init (або його еквівалент) часто називають матір'ю всіх процесів.

Сторінка довідки для «init» посилається на нього як на батьківський для всіх процесів. Згідно з угодою, перша програма або процес ядра, який виконується, завжди має ідентифікатор процесу 1. Після запуску першого процесу він запускає інші служби, демони, процеси, програми тощо.

Для вивчення першого системного процесу¶

Примітка

У наведених нижче вправах замініть PID на ідентифікаційний номер процесу.

Увійдіть у систему як будь-який користувач. Запитайте шлях віртуальної файлової системи /proc/PID/comm і знайдіть назву процесу з ідентифікатором 1. Впишіть:
```
[root@localhost ~]# cat /proc/1/comm

systemd
```
Виконайте команду ls, щоб переглянути шлях до віртуальної файлової системи /proc/PID/exe та побачити назву та шлях до виконуваного файлу процесу з ідентифікатором 1. Впишіть:
```
[root@localhost ~]# ls -l /proc/1/exe

lrwxrwxrwx 1 root root 0 Oct  5 23:56 /proc/1/exe -> /usr/lib/systemd/systemd
```
Спробуйте скористатися командою ps, щоб дізнатися назву процесу або програми, що стоїть за PID. Впишіть:
```
[root@localhost ~]# ps -p 1 -o comm=

systemd
```
Використовуйте команду ps, щоб переглянути повний шлях і будь-які аргументи командного рядка процесу або програми, що стоїть за PID 1. Впишіть:
```
[root@localhost ~]# ps -p  1 -o args=

/usr/lib/systemd/systemd --switched-root --system --deserialize 16
```
Щоб переконатися, що основним процесом, який традиційно називають init, є systemd, використовуйте ls, щоб підтвердити, що init є символічним посиланням на systemd двійковий. Впишіть:
```
[root@localhost ~]# ls -l /usr/sbin/init
lrwxrwxrwx. 1 root root 22 Aug  8 15:33 /usr/sbin/init -> ../lib/systemd/systemd
```
Використовуйте команду pstree, щоб показати системні процеси у вигляді дерева. Впишіть:
```
[root@localhost ~]# pstree --show-pids
```

Завдання 2¶

`systemd` Targets (RUNLEVELS)¶

systemd defines and relies on many different targets for managing the system. У цій вправі ми зосередимося лише на 5 основних цілях. 5 основних цілей, розглянутих у цьому розділі, перераховані тут:

poweroff.target
rescue.target
multi-user.target - Завантажує систему з повною багатокористувацькою підтримкою без графічного середовища.
graphical.target - Завантажує систему з мережею, підтримкою кількох користувачів і менеджером відображення.
reboot.target

Підказка

Цільові одиниці замінюють рівні виконання SysV у класичній системі ініціалізації SysV.

Для керування цілями systemd¶

Перелічіть УСІ (активні + неактивні + невдалі) доступні цілі на сервері.
```
[root@localhost ~]# systemctl list-units --type target --all
```
Перелічіть лише поточні активні цілі. Впишіть:
```
[root@localhost ~]# systemctl list-units -t target    
```
Використовуйте команду systemctl, щоб переглянути/отримати ім’я цілі за умовчанням, для завантаження якої налаштовано систему. Впишіть:
```
[root@localhost ~]# systemctl get-default

multi-user.target
```
Перегляньте вміст файлу юніту для цілі за замовчуванням (multi-user.target). Впишіть:
```
[root@localhost ~]# systemctl cat multi-user.target

# /usr/lib/systemd/system/multi-user.target
........
[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
```
Зверніть увагу на деякі властивості та їхні значення, налаштовані в модулі multi-user.target. Такі властивості, як - Description, Documentation, Requires, After, та інші.

Юніт basic.target указана як значення властивості Requires для multi-user.target. Перегляньте файл блоку для basic.target. Впишіть:

[root@localhost ~]# systemctl cat multi-user.target
# /usr/lib/systemd/system/basic.target
[Unit]
Description=Basic System
Documentation=man:systemd.special(7)
Requires=sysinit.target
Wants=sockets.target timers.target paths.target slices.target
After=sysinit.target sockets.target paths.target slices.target tmp.mount
RequiresMountsFor=/var /var/tmp

Команда systemctl cat показує лише підмножину властивостей і значень певної одиниці. Щоб переглянути дамп УСІХ властивостей і значень цільового блоку, скористайтеся підкомандою show. Команда show також відобразить властивості низького рівня. Показати ВСІ властивості multi-user.target, введіть:
```
[root@localhost ~]# systemctl show  multi-user.target
```

Відфільтруйте властивості Id, Requires і Description із довгого списку властивостей у модулі multi-user.target. Впишіть:

[root@localhost ~]# systemctl --no-pager show \
--property  Id,Requires,Description  multi-user.target

Id=multi-user.target
Requires=basic.target
Description=Multi-User System

Перегляньте служби та ресурси, які залучає multi-user.target під час запуску. Іншими словами, відображати те, що «бажає» multi-user.target. Впишіть:
```
[root@localhost ~]# systemctl show --no-pager -p "Wants"  multi-user.target

Wants=irqbalance.service sshd.service.....
...<SNIP>...
```

Використовуйте команди ls і file, щоб дізнатися більше про зв’язок традиційної програми init з програмою systemd. Впишіть:

[root@localhost ~]# ls -l /usr/sbin/init && file /usr/sbin/init

lrwxrwxrwx. 1 root root 22 Aug  8 15:33 /usr/sbin/init -> ../lib/systemd/systemd
/usr/sbin/init: symbolic link to ../lib/systemd/systemd

Щоб змінити ціль завантаження за замовчуванням¶

Встановити/змінити ціль за замовчуванням, з якої система завантажується. Використовуйте команду systemctl set-default, щоб змінити ціль за замовчуванням на graphical.target. Впишіть:
```
[root@localhost ~]# systemctl set-default graphical.target
```
Перевірте, чи активна щойно встановлена ціль завантаження. Впишіть:
```
[root@localhost ~]# systemctl is-active graphical.target

inactive
```
Зауважте, що вихідні дані показують, що ціль не активна, навіть якщо вона була встановлена як типова!
Щоб змусити систему негайно перейти до заданої цілі та використати її, потрібно використати підкоманду isolate. Впишіть:
```
[root@localhost ~]# systemctl isolate graphical.target
```
Важливо

Команда systemctl isolate може бути небезпечною, якщо її використовувати неправильно. Це тому, що він негайно зупинить процеси, не активовані в новій цілі, можливо, включаючи графічне середовище або термінал, який ви зараз використовуєте!
Перевірте ще раз, чи graphical.target зараз використовується та активний.
Запитуйте та переглядайте, які інші служби чи ресурси «Wants» graphical.target.

Питання

Які основні відмінності між multi-user.target і graphical.target "Wants"?
Оскільки ваша система працює під керуванням операційної системи серверного класу, де повноцінне графічне середовище робочого столу може бути небажаним, перемкніть систему назад до більш відповідного multi-user.target. Впишіть:
```
[root@localhost ~]# systemctl isolate multi-user
```
Встановити/змінити ціль завантаження системи за замовчуванням на multi-user.target.
Запустіть швидку [і додаткову] ручну перевірку, щоб побачити, на яку ціль вказує символічне посилання default.target, виконавши:
```
[root@localhost ~]# ls -l /etc/systemd/system/default.target
```

Завдання 3¶

Вправи в цьому розділі покажуть вам, як налаштувати системні/користувацькі процеси та демони (також відомі як служби), які, можливо, потребуватимуть автоматичного запуску разом із системою.

Щоб переглянути статус послуги¶

Увійшовши в систему як root, перерахуйте всі блоки systemd, які мають певний тип служби. Впишіть:
```
root@localhost ~]# systemctl list-units -t service -all
```
Це покаже повний список активних і завантажених, але неактивних одиниць.

Перегляньте список активних одиниць systemd із типом служби.

[root@localhost ~]# systemctl list-units --state=active --type service
UNIT                LOAD   ACTIVE SUB     DESCRIPTION
atd.service         loaded active running Job spooling tools
auditd.service      loaded active running Security Auditing Service
chronyd.service     loaded active running NTP client/server
crond.service       loaded active running Command Scheduler
dbus.service        loaded active running D-Bus System Message Bus
firewalld.service   loaded active running firewalld - dynamic firewall daemon
...<SNIP>...

Звузьте список і дізнайтеся більше про конфігурацію однієї зі служб у попередніх результатах, crond.service. Впишіть:
```
[root@localhost ~]# systemctl cat crond.service
```
Перевірте, чи crond.service налаштовано на автоматичний запуск під час завантаження системи. Впишіть:
```
[root@localhost ~]# systemctl is-enabled  crond.service

enabled
```
Переглядайте статус служби crond.service у реальному часі. Впишіть:
```
[root@localhost ~]# systemctl  status  crond.service  
```
За замовчуванням вихідні дані включатимуть 10 останніх рядків/записів/журналів журналу.
Перегляньте статус crond.service і припиніть показ будь-яких рядків журналу. Впишіть:
```
[root@localhost ~]# systemctl -n 0  status  crond.service  
```
Переглянути стан sshd.service.

Питання

Перегляньте статус firewalld.service. Що таке юніт firewalld.service?

Щоб зупинити сервіси¶

Увійшовши в систему як користувач із правами адміністратора, скористайтеся командою pgrep, щоб перевірити, чи з’являється процес crond у списку процесів, запущених у системі.
```
[root@localhost ~]# pgrep  -a crond

313274 /usr/sbin/crond -n
```
Якщо вона знаходить відповідну назву процесу, команда pgrep повинна знайти та перерахувати PID crond.
Використовуйте systemctl, щоб зупинити модуль crond.service. Впишіть:
```
[root@localhost ~]# systemctl stop crond.service
```
Команда має завершитися без жодного результату.
Використовуючи systemctl, перегляньте статус crond.service, щоб побачити ефект ваших змін.
Скористайтеся pgrep знову, щоб перевірити, чи процес crond все ще відображається у списку процесів.

Щоб запустити сервіси¶

Увійдіть під обліковим записом адміністратора. Використовуйте команду pgrep, щоб перевірити, чи з’являється процес crond у списку процесів, які виконуються в системі.
```
[root@localhost ~]# pgrep  -a crond
```
Якщо pgrep знайде відповідну назву процесу, він перерахує PID crond.
Використовуйте systemctl, щоб запустити модуль crond.service. Впишіть:
```
[root@localhost ~]# systemctl start crond.service
```
Команда має завершитися без жодних виводів чи видимого зворотного зв’язку.

Використовуючи systemctl, перегляньте статус crond.service, щоб побачити ефект ваших змін. Впишіть:

[root@localhost ~]# systemctl -n 0 status crond.service

● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2023-10-16 11:38:04 EDT; 54s ago
Main PID: 313451 (crond)
    Tasks: 1 (limit: 48282)
Memory: 1000.0K
CGroup: /system.slice/crond.service
        └─313451 /usr/sbin/crond -n

Питання

З результатів команди systemctl status у вашій системі, який PID crond?

Подібним чином знову скористайтеся pgrep, щоб побачити, чи процес crond тепер відображається у списку процесів. Порівняйте PID, показаний pgrep, із PID, показаним у попередньому статусі systemctl crond.service.
```
[root@localhost ~]# systemctl is-enabled  crond.service

enabled
```

Щоб перезапустити сервіси¶

Для багатьох служб/демонов часто потрібне перезапуск або перезавантаження запущеної служби/демона щоразу, коли вносяться зміни до їхніх базових файлів конфігурації. Це робиться для того, щоб даний процес/служба/демон міг застосувати останні зміни конфігурації.

Перегляньте статус crond.service. Впишіть:
```
[root@localhost ~]# systemctl -n 0 status crond.service
```
У вихідних даних зверніть увагу на PID для crond.
Запустіть systemctl restart, щоб перезапустити crond.service. Впишіть:
```
[root@localhost ~]# systemctl -n 0 status crond.service
```
Команда має завершитися без жодних виводів чи видимого зворотного зв’язку.
Знову перевірте статус crond.service. Порівняйте останній PID із PID, зазначеним на кроці 1.
Використовуйте systemctl, щоб перевірити, чи crond.service зараз активний. Впишіть:
```
[root@localhost ~]# systemctl is-active crond.service
active
```
Питання

Чому, на вашу думку, PID відрізняються кожного разу, коли ви перезапускаєте службу?

Порада

Функціональність старої доброї класичної команди служби перенесено для бездоганної роботи в керованих системах systemd. Ви можете використовувати такі команди служби, як наведені нижче, щоб зупинити, запустити, перезапустити та переглянути статус служби smartd.
```
```bash
# service smartd status

# service smartd stop

# service smartd start

# service smartd restart
```
```

Щоб вимкнути послугу¶

Використовуйте systemctl, щоб перевірити, чи ввімкнено crond.service для автоматичного запуску системи. Впишіть:
```
[root@localhost ~]# systemctl is-enabled  crond.service

enabled
```
Зразок результату показує, що це так.

Вимкніть автоматичний запуск crond.service. Впишіть:

[root@localhost ~]# systemctl disable crond.service
Removed /etc/systemd/system/multi-user.target.wants/crond.service.

Знову виконайте команду systemctl is-enabled, щоб побачити ефект ваших змін.

Питання

На сервері, яким потрібно керувати віддалено, чому б вам НЕ вимкнути автоматичний запуск під час завантаження системи такої служби, як sshd.service?

Щоб забезпечити відключення (маскування) сервісу¶

Незважаючи на те, що команду systemctl disable можна використовувати для вимкнення служб, як ви бачили в попередніх вправах, інші елементи systemd (процеси, служби, демони тощо) можуть непомітно - увімкнути відключену службу, якщо потрібно. Це може статися, коли служба залежить від іншої [вимкненої] служби.

Ви повинні замаскувати службу, щоб гарантувати вимкнення служби systemd і запобігти випадковій повторній активації.

Використовуйте systemctl, щоб замаскувати crond.service і запобігти будь-якій небажаній повторній активації, введіть:
```
[root@localhost ~]# systemctl mask crond.service

Created symlink /etc/systemd/system/crond.service → /dev/null.
```
Виконайте команду systemctl is-enabled, щоб переглянути ефект ваших змін.
```
[root@localhost ~]# systemctl is-enabled  crond.service

masked
```
Щоб скасувати зміни та демаскувати crond.service, скористайтеся командою systemctl unmask, виконавши:
```
[root@localhost ~]# systemctl unmask crond.service

Removed /etc/systemd/system/crond.service.
```

Щоб увімкнути сервіс¶

Використовуйте systemctl, щоб перевірити стан блоку crond.service. Впишіть:
```
[root@localhost ~]# systemctl status crond.service
```
Служба все ще має бути в стані зупинки.

Використовуйте команду systemctl enable, щоб увімкнути crond.service для автоматичного запуску. Впишіть:

[root@localhost ~]# systemctl enable crond.service

Created symlink /etc/systemd/system/multi-user.target.wants/crond.service → /usr/lib/systemd/system/crond.service.

Знову скористайтеся systemctl, щоб перевірити, чи активний crond.service. Впишіть:
```
[root@localhost ~]# systemctl is-active crond.service
inactive
```
Питання

Ви щойно ввімкнули crond.service. Чому він не працює або не вказано як активний у попередній команді?
Використовуйте дещо інший варіант команди systemctl enable, щоб увімкнути crond.service і негайно запустити демон. Впишіть:
```
[root@localhost ~]# systemctl --now enable crond.service
```
Перевірте, чи crond.service зараз активний. Впишіть:
```
[root@localhost ~]# systemctl is-active crond.service
active
```
Використовуючи systemctl, переконайтеся, що crond.service запущено, працює та ввімкнено для автоматичного запуску.