systemctl diu que systemd no és PID 1: i ara què?

Executar systemctl start openvpn-client@office i rebre un missatge que diu que el sistema no s’ha iniciat amb systemd sembla una fallada del servei. No és cap fallada del servei: el systemctl que heu invocat no troba cap gestor en execució amb qui parlar, així que no s’ha examinat res relacionat amb OpenVPN. sudo no crea cap gestor, i instal·lar un fitxer d’unitat tampoc no en crea. L’ordre i la màquina venen de dos mons diferents, i l’error és l’únic lloc on això s’ha fet visible.

Comenceu preguntant quin procés té el PID 1 allà on s’executa l’ordre, perquè aquesta resposta decideix si les unitats existeixen o no.

L’error anomena l’entorn, no OpenVPN

systemctl és un client, no un gestor. Es connecta al gestor del sistema mitjançant un sòcol i, quan a l’altre costat no hi ha cap gestor, imprimeix el missatge que la gent enganxa als fòrums. ps -p 1 -o pid=,comm= mostra què s’executa realment com a PID 1, i la resposta sovint és un shell, un embolcall init o el punt d’entrada propi del contenidor. En aquesta situació, un fitxer d’unitat pot ser perfectament vàlid i tot i així no llegir-se mai. Repetir l’ordre com a root només canvia les credencials del client.

Llegiu el missatge sencer abans de la primera línia. Un error del mateix gestor, com ara una unitat absent o una condició fallida, vol dir que hi heu arribat; aquest error vol dir que no.

WSL: activar systemd és un canvi de configuració

WSL va obtenir suport per a systemd en versions posteriors, però la funció s’activa per distribució i només allà on la versió instal·lada de WSL la suporta. wsl --version a la banda de Windows indica què teniu, i el /etc/wsl.conf de la distribució conté [boot] una secció amb systemd=true. Editeu aquest fitxer sense treure les seccions que ja hi són i, després, reinicieu la instància de WSL perquè el canvi tingui efecte. wsl --shutdown atura totes les distribucions en execució, així que deseu la feina abans.

Un cop reobert, confirmeu el gestor abans de tocar la unitat d’OpenVPN: ps -p 1 -o comm= hauria de mostrar systemd. Activar systemd no proporciona cap perfil, cap credencial ni cap nom d’instància, així que el proper error tractarà d’un d’aquests elements i no del PID 1.

Els contenidors executen el seu punt d’entrada, no unitats

Un contenidor normal inicia el que especifica el seu punt d’entrada o la seva ordre, i no és una màquina arrencada amb systemd, siguin quins siguin els paquets que instal·leu. Afegir systemctl a la imatge us dona un client sense res a què connectar-se. Per a Community OpenVPN, el patró compatible sol ser un procés en primer pla, openvpn --config /path/to/client.conf, iniciat pel punt d’entrada i supervisat des de fora. Aquest propietari s’encarrega de l’arrencada, els senyals i l’aturada, i hauria de ser l’única cosa que gestiona el túnel.

No llanceu mai una còpia interactiva al costat d’un punt d’entrada que ja gestiona aquest túnel, perquè dos processos es barallaran pel dispositiu i les rutes. Un procés init mínim dins del contenidor recull els fills i reenvia els senyals; no converteix la imatge en un amfitrió amb unitats.

Si un desplegament necessita realment systemd dins d’un contenidor, necessita una imatge dissenyada expressament per a això, no privilegis addicionals afegits fins que systemctl deixi de queixar-se.

Llegiu el següent error quan el gestor existeixi

Quan un gestor real llança el servei, comencen els errors útils. Una fallada de permisos del dispositiu, un error d’anàlisi de la configuració, una credencial absent i un igual inabastable són quatre problemes diferents que el missatge sobre PID 1 no va provar mai. Llegiu-los en l’ordre en què la unitat els va produir, fent servir journalctl -u openvpn-client@office -n 50 en un amfitrió amb systemd, o executant el client en primer pla allà on no hi ha cap gestor. L’execució en primer pla és també la manera més ràpida de confirmar que el perfil mateix funciona.

Manteniu els dos entorns separats a les vostres notes: l’amfitrió que executa el túnel i el lloc on escriviu ordres.