Як перезавантажити сервер

У цьому посібнику розглянемо та покажемо вам, як ви можете перезавантажити віртуальні та виділені сервери в самій ОС та як перезавантажити віртуальні та виділені сервери через особистий кабінет, а також ми покажемо вам як ви можете перезавантажувати служби на сервері.

Як перезавантажити Linux сервер

Щоб перезавантажити сервер Linux, ви спочатку повинні увійти на нього за допомогою SSH.
Після входу ви повинні виконати команду “reboot” і сервер відразу піде у перезавантаження. За одну хвилину сервер знову стане доступним для роботи.

Відразу після виконання команди сервер стане недоступним. PuTTY показав таке повідомлення, що віддалений сервер закрив інтернет-з'єднання.

Як перезавантажити Windows Server

Ця інструкція підходить для всіх видів, у тому числі для Windows Server 2008 R2 та 2012 R2. Щоб зрозуміти, як перезавантажити сервер, повторіть три простих етапи:

Заходимо до «Пуску» і вибираємо пункт «Виконати».

Набираємо cmd, щоб увімкнути командний рядок.

Для моментального перезавантаження вводимо команду:

Число 0 означає час, через який потрібно перезапустити комп'ютер.

Щоб у майбутньому виконувати всі дії швидше, створіть ярлик або bat-файл.

Через PowerShell

Перезавантажувати через оболонку також просто. Достатньо відкрити її та ввести команду Restart-Computer 1, де замість «1» впишіть ім'я комп'ютера. Якщо потрібно перезавантажити кілька комп'ютерів, перерахуйте їх через кому.

Тепер виконуємо команду

Можна написати скрипт, щоб перезавантажуватися Windows автоматично. Деякі використовують сторонні утиліти, але зазвичай у цьому немає необхідності, оскільки перезавантажити сервер можна стандартними компонентами.

Як перезавантажити віртуальний сервер із особистого кабінету

Перезавантаження віртуального сервера з особистого кабінету є одним і найлегшим перезавантаженням, незалежно від оперативної системи на сервері.
Щоб перезавантажити сервер з особистого кабінету, після входу до нього натисніть на Віртуальні сервери у розділі Товари/Послуги, потім натисніть на сервер, а потім натисніть на кнопку Перезавантаження.

Через приблизно одну хвилину ваш сервер знову буде доступний в мережі і готовий для продовження роботи.

Як перезавантажити виділений сервер із особистого кабінету

Перезавантаження виділеного сервера з особистого кабінету також досить просте, як і перезавантаження віртуального.
Щоб перезавантажити виділений сервер, у розділі Товари/Послуги, натисніть на кнопку Виділені серверипотім на ваш сервер і після цього на кнопку Перезавантаження.

Після перезавантаження потрібно почекати близько п'яти хвилин, щоб сервер знову став доступним для продовження роботи.

Як перезавантажувати служби на сервері Linux

Розуміння systemctl

Існує два офіційні інструменти управління, які забезпечують єдиний спосіб запуску, зупинки, перезапуску та управління системними службами в Linux:

Який із них ви використовуєте, буде залежати від того, чи використовує ваш дистрибутив systemd або initБільшість сучасних дистрибутивів перейшли на systemd, тому кращим менеджером служб є systemctlАле деякі старі звички відмирають насилу, тому багато адміністраторів все ще дотримуються команди застарілого сервісу.

На щастя, розробники systemd подбали про те, щоб зберегти службу та перенаправити її на systemctlСитуація ще більше ускладнюється тим, що ви можете виявити випадкову встановлену вами службу, яка не була оновлена ​​до інструментів служби, ні до інструментів systemctl, і її доведеться запускати вручну за допомогою /etc/rc.d (або /etc/init.d).

Так що це все ще може бути трохи заплутаним.

Але тут ми шукаємо кращі практики, для перезапуску додатків у Linux найкращі практики починаються та закінчуються systemctl.

Перезапуск служби Linux

Щоб перезапустити ту ж службу Apache:

1. Відкрийте термінал.

2. Запустіть команду

CentOS/RHEL:systemctl restart httpd Ubuntu/Debian: systemctl restart apache2

3. Служба перезапуститься, і ви повернетеся до командного рядка.

4. Ви отримаєте таке повідомлення:

The service httpd (apache2 – Debian/Ubuntu) has been restarted успішно.

Якщо служба не запущена, ви побачите наступний висновок:

The service httpd (apache2 – Debian/Ubuntu) is not running.

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

systemctl status httpd

Якщо служба буде запущена, ви отримаєте повідомлення:

Service httpd (apache2 – Debian/Ubuntu) is running.

Аналогічно, ви можете перезавантажити інші служби, як mariadb, mysql, nginx та ін.

Приклади, як перезавантажити інші служби на вашому сервері:

Як перезавантажити веб-сервер NGINX

systemctl restart nginx

Як перезавантажити сервер бази даних MySQL

systemctl restart mysql

Як перезавантажити сервер бази даний MariaDB

systemctl restart mariadb

Як перезавантажити службу фаєрволу Fail2Ban

systemctl restart fail2ban

Як перезавантажити поштовий сервер Exim

Exim: systemctl restart exim

Висновок

Сподіваємося, ця інформація Вам була корисна. У разі питань ми завжди будемо раді Вас проконсультувати в онлайн чаті.

Як налаштувати службу Linux для автоматичного запуску після збою або перезавантаження - частина 1: практичні приклади

У цьому посібнику, що складається з двох частин, ви дізнаєтеся, як налаштувати автоматичний перезапуск служби Linux після перезавантаження або збою за допомогою systemd .

У першій частині розглядаються загальні концепції управління службами Linux, такі як демон init та рівні виконання. Він закінчується демонстрацією управління службами в systemd. Тут ви вивчите файли targets, wants, requires і unit.

Частина друга пропонує покрокове посібник із виконання практичної і поширеної завдання systemd . Зокрема, ви налаштуєте сервер бази даних MySQL для автоматичного запуску після збою або перезавантаження.

Примітка. Ви також можете прочитати наш дуже популярний посібник із використання systemctl для управління службами та модулями systemd.

Передумови

Для виконання цього уроку вам знадобляться:

• Сервер під керуванням CentOS 8, включаючи користувача без повноважень root із привілеями sudo. Щоб налаштувати все це, включаючи брандмауер, ви можете звернутися до Посібника з початкового настроювання сервера.

Знайомство з демоном управління службами

Служби Linux можна зробити самовідновними, в основному, змінивши спосіб їх обробки демоном управління службами, також відомим як демон init.

init це перший процес, який запускається в системі Linux після завантаження машини і завантаження ядра в пам'ять. Крім іншого, він вирішує, як повинен завантажуватися процес користувача або системна служба, в якому порядку і чи повинен він запускатися автоматично.

У міру розвитку Linux змінювалося і поведінка демона init. Спочатку Linux починався з System V init, тієї ж самої, що використовувалася в Unix. З того часу в Linux був реалізований демон Upstart init (створений Ubuntu), а тепер демон systemd init (вперше реалізований Fedora).

Більшість сучасних дистрибутивів Linux поступово відходять від System V і нині використовують systemd. Старий стиль init (якщо використовується) зберігається лише для зворотної сумісності.FreeBSD, варіант UNIX, використовує іншу реалізацію System V, відому як BSD init.

У цій статті ми розглянемо systemd, оскільки це останній і найпоширеніший диспетчер служб, який сьогодні використовується в дистрибутивах Linux. Тим не менш, ми також говоритимемо про System V і Upstart, коли це буде необхідно, і подивимося, як звідти розвинувся systemd. Щоб дати вам уявлення:

• System V - найстаріша система init, що використовувалася в
• Debian 6 і попередні версії
• Ubuntu 9.04 та більш ранні версії
• CentOS 5 і раніше версії
• Upstart з'явився після System V і використовувався в
• Від Ubuntu 9.10 до Ubuntu 14.10, включаючи Ubuntu 14.04
• ЦентрОС 6
• systemd — найновіший менеджер служб Linux, який використовується в
• Debian 7 і вище
• Ubuntu 15.04 та вище
• CentOS 7 і вище

Щоб зрозуміти демона init, давайте почнемо з того, що називається рівнем виконання.

Рівні виконання

Рівень запуску становить поточний стан системи Linux. Наприклад, рівень виконання може бути станом вимкнення сервера Linux, однокористувацьким режимом, режимом перезапуску і т. д. Кожен режим визначає, які служби можуть працювати в цьому стані.

Деякі служби можуть працювати на одному або кількох рівнях виконання, але не на інших. Рівні запуску позначаються від 0 до 6. У наступному списку показано, що означає кожен з цих рівнів:

• Рівень запуску 0: завершення роботи системи
• Рівень запуску 1: однокористувацький, аварійний режим
• Рівні запуску 2, 3, 4: розрахований на багато користувачів, текстовий режим з підтримкою мережі
• Рівень виконання 5: розрахований на багато користувачів, мережевий, графічний режим.
• Рівень виконання 6: перезавантаження системи

Рівні виконання 2, 3 та 4 залежать від дистрибутива. Наприклад, деякі дистрибутиви Linux не реалізують рівень запуску 4, тоді як інші підтримують.Деякі дистрибутиви мають чітку різницю між цими трьома рівнями. Як правило, рівні виконання 2, 3 або 4 означають стан, при якому Linux завантажується в розрахованому на багато користувачів текстовому режимі з підтримкою мережі.

Коли ви включаєте автозапуск служби, Linux фактично додає її до рівня запуску. System V, наприклад, ОС запускається з певного рівня виконання; і коли він запуститься, він спробує запустити всі служби, пов'язані з цим рівнем виконання. У systemd рівень запуску став цільовим, і коли служба автоматично запускається, вона додається до цільової. Ми обговоримо цілі пізніше у цій статті.

Ознайомлення з демоном ініціалізації System V

System V використовує файл inittab, який пізніші методи init зберегли для зворотної сумісності. Давайте пробіжимося по послідовності запуску System V:

1. Демон init створюється із двійкового файлу /sbin/init
2. Перший файл, який читає демон init, це /etc/inittab
3. Один із записів у цьому файлі визначає рівень виконання, з якого повинна завантажуватися машина. Наприклад, якщо значення для рівня виконання вказано як 3, Linux завантажуватиметься в розрахованому на багато користувачів текстовому режимі з включеною мережею. (Цей рівень виконання називається рівнем запуску за замовчуванням)
4. Потім демон init переглядає файл /etc/inittab і читає, які сценарії init йому потрібно запустити для рівня запуску

Таким чином, коли демон init знаходить які сценарії init йому потрібно запустити для заданого рівня запуску, він насправді з'ясовує, які служби йому потрібні для запуску. У цих сценаріях init можна настроїти поведінку під час запуску для окремих служб.

Сценарій init — це те, що керує певною службою в System V. Сценарії init для служб або надаються постачальником програми, або поставляються з дистрибутивом Linux (для власних служб).Ви також можете створити власний скрипт init для створеної користувачем служби.

Коли процес або служба, наприклад MySQL Server, запускається під System V, його двійковий програмний файл повинен завантажуватися в пам'ять. Залежно від того, як настроєно службу, ця програма може безперервно виконуватися у фоновому режимі (і приймати клієнтські підключення). Робота із запуску, зупинки або перезавантаження цієї бінарної програми обробляється скриптом служби init. Він називається сценарієм init, тому що він ініціалізує службу.

System V сценарій init є сценарієм оболонки. Їх називають сценаріями rc (команда запуску). Сценарії знаходяться в каталозі /etc/init.d. Ці скрипти мають символічні посилання каталоги /etc/rc . У каталозі /etc є кілька каталогів rc , кожен із яких має номер у імені. Цифри позначають різні рівні виконання. Отже, у нас є /etc/rc0.d, /etc/rc1.d, /etc/rc2.d і так далі.

Щоб перезапустити службу після збою або перезавантаження, зазвичай можна додати такий рядок до скрипту init :

Щоб запустити службу System V під час завантаження системи, виконайте таку команду:

Щоб вимкнути його, виконайте цю команду:

Щоб перевірити статус (працює або зупинено), виконайте цю команду

Знайомство з демоном Upstart

Оскільки серіалізований спосіб завантаження завдань і служб став більш трудомістким і складним з System V init, було введено демон Upstart для більш швидкого завантаження ОС, витонченого очищення аварійних служб та передбачуваної залежності. між системними службами

Upstart init був кращим, ніж System V init з кількох причин:

• Для завантаження служб та керування ними не використовувалися таємні сценарії оболонки. Натомість він використовує прості конфігураційні файли, які легко зрозуміти і змінити.
• Служби не завантажувалися послідовно, як System V, що скорочує час завантаження системи.
• Використовувалася гнучка система подій для налаштування обробки служб у різних станах.
• Upstart мав найкращі способи обробки того, як аварійний сервіс повинен відновитися.
• Не було необхідності зберігати кілька надмірних символічних посилань, що вказують на той самий скрипт

Для простоти Upstart назад сумісний із System V. Сценарій /etc/init.d/rc, як і раніше, працює для управління власними службами System V. Його основна відмінність полягає в тому, що він дозволяє пов'язати кілька подій зі службою. Ця архітектура, заснована на подіях, дозволила Upstart бути гнучким менеджером послуг. З Upstart кожна подія може запустити сценарій оболонки, який подбає про цю подію. Ці події включали:

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

При запуску Upstart запускатиме будь-які сценарії System V init у звичайному режимі. Потім він переглядає каталог /etc/init та виконує команди оболонки у кожному файлі конфігурації служби. Крім того, ці файли контролювали поведінку служби під час запуску.

Файли мають стиль іменування service_name .conf і містять типовий текст з різними розділами, званими строфами. Кожна строфа визначає окремий аспект служби та її поведінку. Щоб служба запускалася автоматично після збою або перезавантаження, ви можете додати команду respawn до її конфігураційних файлів служби, як показано нижче для служби cron.

. доклад "regular background program processing daemon" start on runlevel [2345] stop on runlevel [!2345] expect fork **respawn** exec cron

Знайомство з демоном systemd

Останнім демоном init у Linux є systemd.Насправді це більше, ніж демон init : systemd - це фреймворк, який включає багато компонентів сучасної системи Linux.

Однією з його функцій є робота як системний і сервісний менеджер для Linux. У цьому ролі systemd керує поведінкою служби у разі збою чи перезавантаження машини. Ви можете прочитати про systemctl у systemd тут.

systemd назад сумісний із командами System V та сценаріями ініціалізації. Це означає, що будь-яка служба System V також працюватиме під керуванням systemd. Це можливо, тому що більшість адміністративних команд Upstart та System V були змінені для роботи в systemd.

Файли конфігурації systemd: файли модулів

В основі systemd лежать юніт-файли. Кожен модульний файл представляє певний системний ресурс. Інформація про ресурс зберігається у юніт-файлі. Файли сервісних модулів – це прості текстові файли (наприклад, файли Upstart .conf) із декларативним синтаксисом. Це спрощує розуміння та зміну файлів.

Основна відмінність між systemd та двома іншими методами init полягає в тому, що systemd відповідає за ініціалізацію сервісних демонів та інших типів ресурсів, таких як шляхи операційної системи пристрою, точки монтування, сокети тощо. буд. Стиль іменування для файлу модуля - service_name.unit_type. Отже, ви побачите такі файли, як dbus.service, sshd.socket або home.mount.

Структура каталогів

У системах на основі Red Hat, таких як CentOS, файли модулів розташовані у двох місцях. Основне розташування - /lib/systemd/system/. Користувацькі файли модулів або існуючі файли модулів, змінені системними адміністраторами, будуть знаходитись у папці /etc/systemd/system .

Якщо юніт-файл з однаковим ім'ям існує в обох місцях, systemd використовуватиме файл з /etc . Припустімо, служба увімкнена для запуску під час завантаження або будь-якого іншого цільового рівня/рівня виконання.У цьому випадку для цього файлу сервісного модуля буде створено символічне посилання у відповідних каталогах /etc/systemd/system . Файли модулів /etc/systemd/system насправді є символічними посиланнями на файли з тим же ім'ям в /lib/systemd/system .

Послідовність ініціалізації systemd: Цільові одиниці

Особливим типом файлу модуля є цільовий модуль.

Ім'я цільового модуля має суфікс .target. Цільові одиниці відрізняються від інших файлів одиниць, оскільки вони не становлять один конкретний ресурс. Швидше, вони становлять стан системи у будь-який момент часу. Цільові модулі роблять це, групуючи та запускаючи кілька файлів модулів, які мають бути частиною цього стану. Таким чином, цілі systemd можна порівняти порівняно з рівнями виконання System V, хоча вони і не збігаються.

Кожна мета має ім'я, а не номер. Наприклад, ми маємо multi-user.target замість runlevel 3 або reboot.target замість runlevel 6 . . Коли сервер Linux завантажується, скажімо, з multi-user.target , він, по суті, переводить сервер на рівень запуску 2, 3 або 4 , що є текстовим режимом. з увімкненою мережею.

Різниця у тому, як він доводить сервер до цієї стадії. На відміну від System V, systemd не запускає служби послідовно. Принагідно він може перевіряти наявність інших сервісів або ресурсів та визначати порядок їх завантаження. Це дозволяє сервісам завантажуватись паралельно.

Ще одна різниця між цільовими модулями та рівнями виконання полягає в тому, що в System V система Linux може існувати лише в одному рівні виконання. Ви можете змінити рівень виконання, але система існуватиме лише на цьому новому рівні виконання. За допомогою systemd цільові юніти можуть бути інклюзивними, що означає, що коли цільовий юніт активується, він може забезпечити завантаження інших цільових юнітів як його частину.

Наприклад, в системі Linux, яка завантажується з графічним інтерфейсом користувача, буде активований graphical.target, що, в свою чергу, автоматично забезпечить завантаження та активацію multi-user.target. У термінах System V це було схоже на одночасну активацію рівнів виконання 3 і 5.

У таблиці нижче порівнюються рівні запуску та цілі:

systemd default.target

systemd default.target еквівалентний рівню запуску System V за промовчанням.

У System V рівень запуску за промовчанням було визначено у файлі inittab. У systemd цей файл замінюється на default.target. Стандартний файл цільового модуля знаходиться в каталозі /etc/systemd/system. Це символічне посилання на один з цільових файлів модулів /lib/systemd/system.

Коли ви змінюєте ціль за замовчуванням, ви по суті відтворюєте це символічне посилання і змінюєте рівень запуску системи.

Файл inittab System V також вказує, з якого каталогу Linux буде виконувати свої сценарії init : це може бути будь-який з каталогів rcn.d. У systemd цільова одиниця за замовчуванням визначає, які одиниці ресурсів будуть завантажені під час завантаження.

Коли блоки активуються, вони активуються все паралельно чи послідовно. Те, як завантажується одиниця ресурсу, може залежати від інших одиниць ресурсів, які потрібні чи потрібні.

Залежність systemd: хоче і вимагає

Systemd хоче і вимагає контролю над тим, як Systemd звертається до залежностей між сервісними демонами.

Як згадувалося раніше, Upstart забезпечує паралельне завантаження сервісів за допомогою файлів конфігурації. У System V служба могла запускатися певному рівні виконання, але її можна було змусити чекати, доки стане доступна інша служба чи ресурс.Аналогічно служби systemd можна змусити завантажувати одну або кілька цілей або чекати, доки інша служба або ресурс не стануть активними.

У systemd модуль, якому потрібен інший модуль, не запуститься, доки необхідний модуль не буде завантажений та активований. Якщо потрібний блок з будь-якої причини вийде з ладу, поки активний перший блок, перший блок також зупиниться.

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

Практичний приклад: розуміння послідовності запуску systemd

Щоб зрозуміти поведінку запуску служби в systemd ми використовуємо краплю CentOS 8.3. Ми будемо слідувати кролячою стежкою .target наскільки це можливо. Послідовність запуску systemd слід довгим ланцюжком залежностей.

По-перше, давайте запустимо цю команду, щоб вивести файл цільового модуля за замовчуванням:

Це показує висновок, як показано нижче:

Output
lrwxrwxrwx. 1 root root 37 Dec 4 17:42 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

Як бачите, ціль за замовчуванням насправді є символічним посиланням на розрахований на багато користувачів цільовий файл в папці /lib/systemd/system/. Таким чином, передбачається, що система завантажується під multi-user.target, що аналогічно рівню запуску 3 System V init.

розрахована на багато користувачів.

Потім запустимо наступну команду, щоб перевірити всі служби, які потрібні файлу multi-user.target:

Це має показати список файлів символічних посилань, що вказують на фактичні файли модулів /usr/lib/systemd/system/:

Output
lrwxrwxrwx.1 root root 38 Dec 4 17:38 /etc/systemd/system/multi-user.target.wants/auditd.service -> /usr/lib/systemd/system/auditd.service lrwxrwxrwx. 1 root root 39 Dec 4 17:39 /etc/systemd/system/multi-user.target.wants/chronyd.service -> /usr/lib/systemd/system/chronyd.service lrwxrwxrwx. 1 root root 37 Dec 4 17:38 /etc/systemd/system/multi-user.target.wants/crond.service -> /usr/lib/systemd/system/crond.service lrwxrwxrwx. 1 root root 42 Dec 4 17:39 /etc/systemd/system/multi-user.target.wants/irqbalance.service -> /usr/lib/systemd/system/irqbalance.service lrwxrwxrwx. 1 root root 37 Dec 4 17:41 /etc/systemd/system/multi-user.target.wants/kdump.service -> /usr/lib/systemd/system/kdump.service .

Крім multi-user.target, існують інші типи цілей, такі як system-update.target або basic.target. Щоб побачити, від яких цілей залежить розрахована на багато користувачів мета, виконайте наступну команду:

Output
Requires=basic.target

базова.мета

Ви можете запустити наступну команду, щоб побачити, чи є якісь необхідні одиниці виміру для basic.target:

Як виявилося, для basic.target потрібно sysinit.target:

Output
Requires=sysinit.target -.mount

І він також хоче кілька цілей:

Команда поверне таке:

Output
Wants=slices.target paths.target timers.target microcode.service sockets.target sysinit.target

Продовжуючи рекурсію, ви можете побачити, чи вимагатиме sysinit.target запуску будь-яких інших цілей:

Їх не буде. Однак для sysinit.target будуть потрібні й інші цілі:

З'явиться такий висновок:

Output
Wants=systemd-random-seed.service dev-mqueue.mount rngd.service systemd-modules-load.service proc-sys-fs-binfmt_misc.automount local-fs.target sys-fs-fuse-connections.mount systemd-sysusers .service systemd-update-done.service systemd-update-utmp.service systemd-journal-flush.service dev-hugepages.mount dracut-shutdown.service swap.target systemd-udevd.service import-state.service sys-kernel-debug.mount nis-domainname.service systemd -journald.service selinux-autorelabel-mark.service kmod-static-nodes.service loadmodules.service ldconfig.service cryptsetup.target systemd-sysctl.service systemd-ask-password-console.path systemd-journal-catalog-update.service systemd-udev-trigger.service systemd-tmpfiles setup.service systemd-hwdb-update.service sys-kernel-config.mount systemd-binfmt.service systemd-tmpfiles-setup-dev.service systemd-machine-id-commit.service systemd-firstboot.service

Вивчення файлу модуля systemd

Зробивши ще один крок, давайте заглянемо у файл сервісного модуля, який для sshd:

[Unit] Description=OpenSSH server daemon Documentation=man:sshd(8) man:sshd_config(5) After=network.target sshd-keygen.target Wants=sshd-keygen.target [Service] Type=notify EnvironmentFile=-/etc /crypto-policies/back-ends/opensshserver.config EnvironmentFile=-/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY ExecReload=/bin/kill -HUP $MAINPID KillMode=процесс Restart=on-failure RestartSec=42s [Install] WantedBy= -user.target

Ви можете бачити, що файл сервісної одиниці є чистим і зрозумілим.

Першою важливою частиною є пропозиція After у розділі [Unit]. Це свідчить про те, що служба sshd має завантажуватися після завантаження network.target та sshd-keygen.target.

Розділ [Install] показує, що потрібна служба multi-user.target. Це означає, що multi-user.target завантажить демон sshd, але не вимкнеться і не впаде, якщо sshd вийде з ладу під час завантаження.

Оскільки multi-user.target є за промовчанням, демон sshd повинен запускатися під час завантаження. У розділі [Service] параметр Restart має значення при збої . Цей параметр дозволяє перезапускати демон sshd у разі його збою чи некоректного виходу.

Висновок

У цій статті ви дізналися про демони управління службами System V, Upstart та systemd. Ви вивчили сценарії запуску та файли конфігурації, важливі параметри, послідовність запуску та команди, які керують поведінкою служби під час запуску.

У другій частині цієї статті ми застосуємо ці навички до реального прикладу та використовуємо systemd для налаштування MySQL. Після завершення ваш екземпляр MySQL автоматично перезапуститься після перезавантаження або збою. І хоча ви будете використовувати MySQL як приклад програми, ви можете замінити будь-яку кількість сервісів, таких як веб-сервери Nginx або Apache.

Статті з цієї тематики:

• Налаштуйте аудіовхід/вихід через WirePlumber в Ubuntu 24.04
• Увімкнення, вимкнення та налаштування брандмауера в Ubuntu 24.04 [Посібник для початківців]
• Як встановити та налаштувати Fail2ban для ще більшої безпеки SSH
• Як налаштувати периферійні пристрої Razer в Ubuntu 16.04, 18.04
• Налаштуйте гарнітуру Logitech або SteelSeries в Ubuntu за допомогою цієї програми
• Як встановити та налаштувати віконний менеджер AfterStep в Ubuntu
• Як встановити антивірус ClamAV на CentOS
• Встановіть та настройте DNS-сервер в Ubuntu 16.04 LTS.
• Встановлення та налаштування модулів у NethServer
• Налаштування статичної та динамічної IP-адреси в Arch Linux
• Найпростіший спосіб встановити та налаштувати сервер OpenVPN у Linux
• Як встановити та налаштувати сервер Redis в Ubuntu
• Як налаштувати віртуальні хости Apache в Ubuntu 18.04 LTS
• Налаштування підтримки миші для віртуальних консолей Linux
• Як легко та швидко налаштувати загальносистемні налаштування проксі-сервера

Автоматичний перезапуск сервісу Linux

Іноді послуги ні з того ні з сього падають і доводиться їх вручну відновлювати. Якщо для користувача домашнього комп'ютера це не критично, тому що якщо сервіс падає під час розробки, це навіть добре, можна відразу побачити що є проблема. Але на серверах та VPS сервіси повинні працювати постійно для забезпечення доступу до веб-сайту або додатку.

У цій інструкції я покажу як налаштувати автоматичний перезапуск сервісу Linux декількома способами: за допомогою скрипта моніторингу, що періодично запускається через cron і systemd.

Автоматичний перезапуск сервісу в systemd

За промовчанням, якщо ваш сервіс буде вбитий або завершиться некоректно, systemd не буде з ним нічого робити. Але можна налаштувати сервіс так, щоб при падінні або зупинці він автоматично перезапускався. Для цього використовується директива Restart, яку треба додати до секції Service. Цей параметр може мати такі значення:

• on-failure - Тільки якщо сталася помилка;
• on-success - Тільки якщо процес сервісу завершився без помилок;
• on-abnormal - Тільки якщо сервіс не відповідає;
• always - перезапускати завжди, коли сервіс було зупинено;

Наприклад, розглянемо налаштування автоматичного перезапуску сервісу Apache:

sudo systemctl edit apache2 [Service]
Restart=on-failure
RestartSec=5s

Директива RestartSec вказує скільки чекати перед перезапуском сервісу. Коли завершите збережіть зміни та виконайте команду daemon-reload, щоб перечитати конфігурацію:

sudo systemctl daemon-reload

Потім, щоб перевірити, що все працює, подивіться стан процесу, завершіть процес сигналом. kill:

sudo systemctl status apache2 kill -KILL 32091

І знову перегляньте стан.Процес буде запущено. Система ініціалізації автоматично перезапустить його, як тільки він завершиться з кодом повернення помилки. Якщо ви хочете, щоб процес перезапускався завжди, необхідно використовувати директиву Restart: always. Однак з нею треба бути обережним, вона зовсім не дасть вам завершити процес, навіть якщо буде потрібно. Для того, щоб процес, який постійно падає, не перезапускався, можна додати ліміт на кількість перезапусків у секцію Service:

sudo systemctl edit apache2 [Service]
StartLimitIntervalSec=500
StartLimitBurst=5
Restart=on-failure
RestartSec=5s

Директиви StartLimitBurst і StartLimitIntervalSec вказують, що треба спробувати перезапустити сервіс п'ять разів, і якщо він усі ці п'ять разів впаде, то більше його не чіпати. Друга директива обмежує час перезапуску сервісу до 500 секунд.

Автоматичний перезапуск сервісу за допомогою скрипту

Це найпростіший і найнадійніший спосіб, що працює абсолютно у всіх дистрибутивах Linux і не вимагає установки додаткових утиліт. Для того ж Apache скрипт виглядає так:

sudo vi /usr/local/bin/apache-monitor.sh #!/bin/bash
ps-A | grep apache2 | systemctl start apache2

Збережіть файл, зробіть його виконуваним:

Тепер додайте запис до cron для періодичного запуску скрипту:

sudo crontab -e */5 * * * * /usr/local/bin/apache-monitor.sh

На цьому все, автоматичний перезапуск сервісів, штука може і трохи складна, але необхідна в серйозних системах.