systemctl паведамляе, што systemd — не PID 1: што далей?
Паведамленне пра PID 1 тычыцца асяроддзя, а не OpenVPN. Праверце, які працэс займае PID 1, уключыце systemd там, дзе ён падтрымліваецца, і прачытайце сапраўдную памылку.
Калі systemctl start openvpn-client@office запускаецца і ў адказ прыходзіць паведамленне, што сістэма не была загружана з systemd, гэта выглядае як збой службы. Насамрэч гэта зусім не збой службы: systemctl, які вы выклікалі, не можа знайсці працуючы кіраўнік, каб з ім звязацца, таму нічога пра OpenVPN не было праверана. sudo не стварае кіраўніка, і ўсталяванне файла юніта таксама яго не стварае. Каманда і машына паходзяць з двух розных светаў, і памылка — адзінае месца, дзе гэта выявілася.
Пачніце з пытання, які працэс валодае PID 1 там, дзе выконваецца каманда, бо гэты адказ вырашае, ці існуюць юніты наогул.
Памылка называе асяроддзе, а не OpenVPN
systemctl — гэта кліент, а не кіраўнік. Ён звязваецца з сістэмным кіраўніком праз сокет, і калі на другім канцы кіраўніка няма, ён выводзіць паведамленне, якое людзі ўстаўляюць на форумы. ps -p 1 -o pid=,comm= паказвае, што насамрэч працуе як PID 1, і адказам часта бывае абалонка, init-абгортка або ўласная кропка ўваходу кантэйнера. У такой сітуацыі файл юніта можа быць цалкам слушным і ўсё роўна ніколі не чытацца. Паўтор каманды ад імя root змяняе толькі ўліковыя даныя кліента.
Прачытайце ўсё паведамленне цалкам, перш чым першы радок. Памылка ад самога кіраўніка, напрыклад адсутны юніт або няўдалая ўмова, азначае, што вы да яго дабраліся; гэтая памылка азначае, што не.
WSL: уключэнне systemd — гэта змена канфігурацыі
WSL атрымаў падтрымку systemd у пазнейшых выпусках, але функцыя ўключаецца асобна для кожнага дыстрыбутыва і толькі там, дзе яе падтрымлівае ўсталяваная версія WSL. wsl --version на баку Windows паказвае, што ў вас ёсць, а файл /etc/wsl.conf дыстрыбутыва змяшчае [boot] раздзел з systemd=true. Рэдагуйце гэты файл, не выдаляючы ўжо наяўныя раздзелы, затым перазапусціце асобнік WSL, каб змена набыла моц. wsl --shutdown спыняе ўсе працуючыя дыстрыбутывы, таму спачатку захавайце працу.
Пасля паўторнага адкрыцця пацвердзіце кіраўнік, перш чым кранаць юніт OpenVPN: ps -p 1 -o comm= павінна паказаць systemd. Уключэнне systemd не дае ні профілю, ні ўліковых даных, ні назвы асобніка, таму наступная памылка будзе пра адзін з гэтых пунктаў, а не пра PID 1.
Кантэйнеры запускаюць сваю кропку ўваходу, а не юніты
Звычайны кантэйнер запускае тое, што вызначаюць яго кропка ўваходу або каманда, і ён не з'яўляецца машынай, загружанай з systemd, якія б пакеты вы ні ўсталявалі. Даданне systemctl у вобраз дае вам кліент, якому няма з чым злучыцца. Для Community OpenVPN падтрымліваемы шаблон — звычайна працэс на пярэднім плане, openvpn --config /path/to/client.conf, запушчаны кропкай уваходу і які кантралюецца звонку. Гэты ўладальнік займаецца запускам, сігналамі і спыненнем, і ён павінен быць адзіным, хто кіруе тунэлем.
Ніколі не запускайце інтэрактыўную копію побач з кропкай уваходу, якая ўжо кіруе гэтым тунэлем, бо два працэсы будуць біцца за прыладу і маршруты. Мінімальны init-працэс унутры кантэйнера збірае даччыныя працэсы і перадае сігналы; ён не робіць вобраз хостам з юнітамі.
Калі разгортванне сапраўды патрабуе systemd унутры кантэйнера, яму патрэбен наўмысна спраектаваны вобраз, а не дадатковыя прывілеі, якія дадаюцца, пакуль systemctl не перастане скардзіцца.
Чытайце наступную памылку, калі кіраўнік ужо ёсць
Як толькі сапраўдны кіраўнік запусціць службу, пачынаюцца карысныя памылкі. Збой правоў прылады, памылка разбору канфігурацыі, адсутныя ўліковыя даныя і недасягальны партнёр — гэта чатыры розныя праблемы, якія паведамленне пра PID 1 ніколі не правярала. Чытайце іх у тым парадку, у якім іх спарадзіў юніт, з дапамогай journalctl -u openvpn-client@office -n 50 на host-е з systemd, або запусціўшы кліент на пярэднім плане там, дзе кіраўніка няма. Запуск на пярэднім плане — таксама хутчэйшы спосаб пераканацца, што сам профіль працуе.
Трымайце два асяроддзі асобна ў сваіх нататках: host, які запускае тунэль, і месца, дзе вы набіраеце каманды.