Файл PID є, тунелю немає: чи запускався OpenVPN взагалі?

Коли програма запуску відмовляється стартувати OpenVPN, бо файл PID уже існує, природне прочитання — десь працює тунель. Це прочитання помилкове достатньо часто, щоб його варто було перевірити, перш ніж щось видаляти. Файл у каталозі виконання — це облік, а облік переживає падіння, перезавантаження й перервані зупинки, що не залишили процесу. Справу вирішують два питання: чи є живий процес і чи належить він цьому примірнику.

Починайте зі служби, а не з файлу

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

Прочитайте юніт або скрипт, що надрукував повідомлення, і зверніть увагу на три речі: шлях, який він перевіряє, тип служби, який він оголошує, і чи відповідає він узагалі за запис файлу. Сучасний юніт може використовувати простий нагляд або нагляд через сповіщення й ніколи не торкатися файлу PID, тоді як старий init-скрипт може створити його сам. Копіювання перевірки з однієї моделі в іншу дає саме таку відмову. З'ясуйте, яка модель використовується, перш ніж щось тлумачити.

Лише тоді питання стає таким: чи справді працює примірник.

Перевірте, чи належить цей ідентифікатор вашому примірнику

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

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

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

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Що програма запуску обіцяла зробити з файлом

PIDFile= повідомляє менеджеру служб, звідки читати ідентифікатор основного процесу. Менеджер не пише цей файл, але видаляє залишений після зупинки, і саме тому перерваний вихід може залишити файл.

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

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

Чиста зупинка проти перерваного виходу

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

Порівняйте часову позначку файлу з останнім завантаженням і з останньою зупинкою юніта.

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

Перестаньте видаляти файл за звичкою

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

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

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