Політика перезапуску, додана для одного тунелю, починає застосовуватися до кожного тунелю на машині. Це не помилка systemd; це різниця між drop-in примірника і drop-in шаблону. Шлях, під яким ви записуєте файл, визначає, скільки служб його успадкують.

Виберіть область до налаштування. Два каталоги виглядають майже однаково, і лише один із них обмежений потрібним вам примірником.

Симптом: одна правка, усі тунелі

Drop-in конкретного примірника лежить у каталозі, названому за повним примірником, наприклад [email protected]. Drop-in шаблону лежить у [email protected], зі знаком @ і без імені примірника між ними. Перший застосовується лише до office. Другий застосовується до кожної служби, створеної з цього шаблону.

Форма шаблону не досягає окремого шаблону [email protected] і не досягає незв’язаних служб, у назві яких є openvpn.

Виберіть каталог, що відповідає області

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

Drop-in також потребує правильного заголовка секції. Налаштування служби належать під [Service]. Файл із налаштуваннями, але без секції, ігнорується або відхиляється, і unit продовжує поводитися як раніше, поки файл лежить там і виглядає переконливо.

Зберігайте призначення в імені файлу, якщо додаєте більше одного drop-in. Порядок об’єднання визначає лексикографічний порядок, і ім’я, що каже, що робить файл, робить цей порядок читабельним.

Прочитайте об’єднаний unit перед записом

Прочитайте об’єднаний unit, перш ніж щось писати. systemctl cat [email protected] друкує основний unit і кожен застосовний drop-in у порядку об’єднання. Порівняйте його з другим примірником, коли розглядаєте зміну шаблону. Це порівняння точно показує, які служби успадкують правку.

Файл примірника не стирає налаштування шаблону. Обидва об’єднуються, тому забуте значення шаблону може все ще діяти.

Беруть участь й інші іменовані drop-in, налаштування часу виконання та конфігурація від пакетів. Не вважайте, що останній відредагований файл — це весь unit. Об’єднаний вивід і є unit.

Тримайте політику unit поза профілем

Тримайте політику unit і конфігурацію VPN окремо. Директива профілю не стає допустимим синтаксисом systemd лише тому, що стоїть під [Service]. Налаштування перезапуску також не належить до файлу .ovpn.

Це розділення — також причина, чому політика перезапуску не те саме, що відновлення пірів, яке виконує OpenVPN сам. Вирішіть, якої поведінки ви хочете, перш ніж вибирати область.

Застосуйте й перевірте примірник

Після зміни перезавантажте визначення менеджера за допомогою systemctl daemon-reload. Це перезавантаження не перезапускає тунель; воно лише перечитує файли unit. Потім застосуйте задуману дію життєвого циклу до точного примірника.

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

Якщо політика справді спільна, навмисно перенесіть її до шаблону й перевірте другий примірник, перш ніж вважати справу завершеною.Довідник з unit systemd документує пріоритет drop-in і порядок об’єднання.

Схожі статті