systemctl hovorí, že systemd nie je PID 1: čo teraz?

Keď sa systemctl start openvpn-client@office spustí a objaví sa správa, že systém nebol nabootovaný so systemd, vyzerá to ako zlyhanie služby. Vôbec to nie je zlyhanie služby: systemctl, ktorý ste zavolali, nenájde bežiaceho správcu, s ktorým by hovoril, takže o OpenVPN sa nič neskúmalo. sudo správcu nevytvára a inštalácia súboru unit ho tiež nevytvorí. Príkaz a stroj pochádzajú z dvoch rôznych svetov a chyba je jediné miesto, kde sa to ukázalo.

Začnite otázkou, ktorý proces vlastní PID 1 tam, kde sa príkaz spúšťa, pretože táto odpoveď rozhoduje, či unit vôbec existujú.

Chyba pomenúva prostredie, nie OpenVPN

systemctl je klient, nie správca. Pripája sa k systémovému správcovi cez socket, a keď na druhej strane žiadny správca nie je, vypíše správu, ktorú ľudia vkladajú na fóra. ps -p 1 -o pid=,comm= ukazuje, čo skutočne beží ako PID 1, a odpoveďou je často shell, init obal alebo vlastný vstupný bod kontajnera. V takej situácii môže byť súbor unit úplne platný a napriek tomu sa nikdy neprečíta. Opakovanie príkazu ako root mení len prihlasovacie údaje klienta.

Prečítajte si celú správu pred prvým riadkom. Chyba od samotného správcu, napríklad chýbajúci unit alebo nesplnená podmienka, znamená, že ste sa k nemu dostali; táto chyba znamená, že nie.

WSL: zapnutie systemd je zmena konfigurácie

WSL získal podporu systemd v neskorších verziách, ale funkcia sa zapína pre každú distribúciu osobitne a len tam, kde ju podporuje nainštalovaná verzia WSL. wsl --version na strane Windows ukáže, čo máte, a /etc/wsl.conf distribúcie obsahuje [boot] sekciu s systemd=true. Upravte tento súbor bez odstránenia už prítomných sekcií a potom reštartujte inštanciu WSL, aby sa zmena prejavila. wsl --shutdown zastaví každú bežiacu distribúciu, takže najprv uložte prácu.

Po opätovnom otvorení potvrďte správcu, než sa dotknete unitu OpenVPN: ps -p 1 -o comm= by malo hlásiť systemd. Zapnutie systemd nedodá žiadny profil, prihlasovacie údaje ani názov inštancie, takže ďalšia chyba sa bude týkať jedného z toho, nie PID 1.

Kontajnery spúšťajú svoj vstupný bod, nie unity

Bežný kontajner spustí to, čo určí jeho vstupný bod alebo príkaz, a nie je to stroj nabootovaný so systemd, nech inštalujete akékoľvek balíky. Pridanie systemctl do image vám dá klienta, ktorý sa nemá k čomu pripojiť. Pre Community OpenVPN je podporovaný vzor zvyčajne proces v popredí, openvpn --config /path/to/client.conf, spustený vstupným bodom a sledovaný zvonku. Ten vlastník sa stará o štart, signály a vypnutie a mal by byť jediný, kto spravuje tunel.

Nikdy nespúšťajte interaktívnu kópiu vedľa vstupného bodu, ktorý už ten tunel spravuje, pretože dva procesy sa budú naťahovať o zariadenie a trasy. Minimálny init proces v kontajneri zberá deti a posiela signály ďalej; nerobí z image hostiteľa s unitmi.

Ak nasadenie naozaj potrebuje systemd v kontajneri, potrebuje image zámerne navrhnutý na to, nie ďalšie oprávnenia pridávané, kým sa systemctl neprestane sťažovať.

Prečítajte si ďalšiu chybu, keď správca existuje

Hneď ako skutočný správca spustí službu, začnú užitočné chyby. Zlyhanie oprávnenia k zariadeniu, chyba pri parsovaní konfigurácie, chýbajúce prihlasovacie údaje a nedostupný partner sú štyri rôzne problémy, ktoré správa o PID 1 nikdy netestovala. Čítajte ich v poradí, v akom ich unit vytvoril, pomocou journalctl -u openvpn-client@office -n 50 na hostiteľovi so systemd, alebo spustením klienta v popredí tam, kde žiadny správca nie je. Spustenie v popredí je aj najrýchlejší spôsob, ako potvrdiť, že samotný profil funguje.

V poznámkach držte obe prostredia oddelene: hostiteľa, ktorý spúšťa tunel, a miesto, kde píšete príkazy.