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

Цілі¶

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

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

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

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

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

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

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

`systemd`¶

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

`systemd` units¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Завдання 1¶

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

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

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

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

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

Note

У наведених нижче вправах замініть 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 визначає та спирається на багато різних цілей для керування системою. У цій вправі ми зосередимося лише на 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 basic.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
```

!!! Warning "Важливо"

    ```
     Команда systemctl isolate може бути небезпечною, якщо її використовувати неправильно. Це пояснюється тим, що вона негайно зупинить процеси, не ввімкнені в новому цільовому об'єкті, можливо, включаючи графічне середовище або термінал, який ви зараз використовуєте!
    ```

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

!!! Question "Питання"

    ```
     Які основні відмінності між 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.

!!! Question "Питання"

    ```
     Переглянути стан `firewalld.service`. Що таке модуль `firewalld.service`?
    ```

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

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

313274 /usr/sbin/crond -n
```

Якщо команда pgrep знайде відповідне ім'я процесу, вона повинна знайти та вивести PID crond.

Використайте systemctl для зупинки модуля cron.service. Впишіть:
```
[root@localhost ~]# systemctl stop crond.service
```

Команда має завершитися без жодного результату.

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

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

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

Якщо pgrep знаходить відповідну назву процесу, він виведе PID crond.

Використайте systemctl для запуску модуля cron.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

!!! Question "Питання"

    ```
     Згідно з виводом команди status `systemctl` у вашій системі, який 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
```

!!! Question "Питання"

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

!!! Tip "Підказка"

    ```
     Функціональність старої доброї класичної команди service була перенесена для безперебійної роботи на системах, керованих systemd. Ви можете використовувати команди service, такі як наведені нижче, для зупинки, запуску, перезапуску та перегляду стану служби `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, щоб побачити ефект від ваших змін.

!!! Question "Питання"

    ```
     На сервері, яким потрібно керувати віддалено, чому б НЕ вимикати автоматичний запуск служби, такої як `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
```

!!! Question "Питання"

    ```
     Ви щойно ввімкнули `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 запущено, працює та увімкнено для автоматичного запуску.

Author: Wale Soyinka

Contributors: Steven Spencer, Ganna Zhyrnova

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

Цілі¶

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

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

systemd¶

systemd units¶

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

Завдання 1¶

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

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

Завдання 2¶

systemd Targets (RUNLEVELS)¶

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

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

Завдання 3¶

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

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

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

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

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

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

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

`systemd`¶

`systemd` units¶

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

`systemd` Targets (RUNLEVELS)¶