systemctl каже, що systemd — не PID 1: і що далі?

Якщо systemctl start openvpn-client@office запускається і з'являється повідомлення, що систему завантажено не з systemd, це виглядає як збій служби. Але це зовсім не збій служби: systemctl, який ви викликали, не знаходить працюючого менеджера, з яким можна поговорити, тому нічого про OpenVPN перевірено не було. sudo не створює менеджера, і встановлення файлу unit теж його не створює. Команда й машина походять із двох різних світів, і помилка — єдине місце, де це проявилося.

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

Помилка називає середовище, а не OpenVPN

systemctl — це клієнт, а не менеджер. Він підключається до системного менеджера через сокет, і коли на іншому кінці менеджера немає, виводить те саме повідомлення, яке люди вставляють на форумах. ps -p 1 -o pid=,comm= показує, що насправді працює як PID 1, і відповіддю часто є оболонка, обгортка init або власна точка входу контейнера. У такій ситуації файл unit може бути цілком коректним і все одно ніколи не прочитаним. Повтор команди від root змінює лише облікові дані клієнта.

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

WSL: увімкнення systemd — це зміна конфігурації

WSL отримав підтримку systemd у пізніших випусках, але функція вмикається для кожного дистрибутива окремо і лише там, де її підтримує встановлена версія WSL. wsl --version на боці Windows показує, що у вас є, а /etc/wsl.conf дистрибутива містить [boot] розділ з systemd=true. Відредагуйте цей файл, не видаляючи вже наявні розділи, потім перезапустіть екземпляр WSL, щоб зміна набула чинності. wsl --shutdown зупиняє кожен працюючий дистрибутив, тому спершу збережіть роботу.

Після повторного відкриття підтвердьте менеджер, перш ніж торкатися unit OpenVPN: ps -p 1 -o comm= має показати systemd. Увімкнення systemd не дає ні профілю, ні облікових даних, ні назви екземпляра, тому наступна помилка стосуватиметься одного з цього, а не PID 1.

Контейнери запускають свою точку входу, а не файли unit

Звичайний контейнер запускає те, що задає його точка входу або команда, і він не є машиною, завантаженою з systemd, які б пакети ви не встановлювали. Додавання systemctl в образ дає вам клієнт, якому нема до чого підключитися. Для Community OpenVPN підтримуваний шаблон — зазвичай процес на передньому плані, openvpn --config /path/to/client.conf, який запускає точка входу і який контролюють ззовні. Той власник відповідає за запуск, сигнали й зупинку, і він має бути єдиним, хто керує тунелем.

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

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

Читайте наступну помилку, коли менеджер уже є

Щойно справжній менеджер запускає службу, починаються корисні помилки. Відмова в правах на пристрій, помилка розбору конфігурації, відсутні облікові дані й недосяжний партнер — це чотири різні проблеми, які повідомлення про PID 1 ніколи не перевіряло. Читайте їх у тому порядку, у якому їх створив unit, за допомогою journalctl -u openvpn-client@office -n 50 на хості з systemd або запустивши клієнт на передньому плані там, де менеджера немає. Запуск на передньому плані — ще й найшвидший спосіб переконатися, що сам профіль працює.

Тримайте два середовища окремо у своїх нотатках: хост, який запускає тунель, і місце, де ви набираєте команди.