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 или като стартирате клиента на преден план там, където няма мениджър. Стартирането на преден план е и най-бързият начин да потвърдите, че самият профил работи.

Дръжте двете среди отделно в бележките си: хоста, който пуска тунела, и мястото, където пишете команди.