systemctl вели дека systemd не е PID 1: што потоа?

Ако systemctl start openvpn-client@office се стартува и се добие порака дека системот не е подигнат со systemd, тоа изгледа како дефект на услугата. Тоа воопшто не е дефект на услугата: systemctl, кој го повикавте, не може да најде работен менаџер со кого би разговарал, па ништо за OpenVPN не е испитано. sudo не создава менаџер, а ниту инсталирањето на unit-датотека создава еден. Наредбата и машината доаѓаат од два различни света, а грешката е единственото место каде тоа се покажа.

Започнете со прашањето кој процес го поседува PID 1 таму каде што се извршува наредбата, бидејќи тој одговор одлучува дали unit-датотеките воопшто постојат.

Грешката ја именува околината, а не OpenVPN

systemctl е клиент, а не менаџер. Се поврзува со системскиот менаџер преку socket, и кога од другата страна нема менаџер, ја печати пораката што луѓето ја лепат на форумите. ps -p 1 -o pid=,comm= покажува што навистина работи како PID 1, а одговорот често е shell, 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-хост, или со стартување на клиентот во преден план таму каде што нема менаџер. Стартувањето во преден план е и најбрзиот начин да потврдите дека самиот профил работи.

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