systemctl dice che systemd non è PID 1: e adesso?
Il messaggio su PID 1 riguarda l’ambiente, non OpenVPN. Verifica cosa gira come PID 1, abilita systemd dove è supportato e poi leggi l’errore reale.
Eseguire systemctl start openvpn-client@office e ricevere un messaggio che il sistema non è stato avviato con systemd sembra un guasto del servizio. Non è affatto un guasto del servizio: il systemctl che hai invocato non trova nessun gestore in esecuzione con cui parlare, quindi nulla riguardo a OpenVPN è stato esaminato. sudo non crea un gestore, e installare un file unit non ne crea uno. Il comando e la macchina vengono da due mondi diversi, e l’errore è l’unico punto in cui questo è emerso.
Inizia chiedendo quale processo possiede il PID 1 là dove viene eseguito il comando, perché quella risposta decide se le unit esistono davvero.
L’errore nomina l’ambiente, non OpenVPN
systemctl è un client, non un gestore. Si connette al gestore di sistema tramite un socket e, quando dall’altra parte non c’è nessun gestore, stampa il messaggio che le persone incollano nei forum. ps -p 1 -o pid=,comm= mostra cosa gira realmente come PID 1, e la risposta è spesso una shell, un wrapper init o il punto di ingresso del container stesso. In quella situazione un file unit può essere del tutto valido e non venire mai letto. Ripetere il comando come root cambia solo le credenziali del client.
Leggi l’intero messaggio prima della prima riga. Un errore dal gestore stesso, come un’unità mancante o una condizione fallita, significa che ne hai raggiunto uno; questo errore significa che non l’hai fatto.
WSL: abilitare systemd è una modifica di configurazione
WSL ha ottenuto il supporto a systemd nelle versioni successive, ma la funzione si abilita per distribuzione e solo dove la versione installata di WSL la supporta. wsl --version sul lato Windows mostra cosa hai, e il /etc/wsl.conf della distribuzione contiene [boot] una sezione con systemd=true. Modifica quel file senza eliminare le sezioni già presenti, poi riavvia l’istanza WSL perché la modifica abbia effetto. wsl --shutdown arresta ogni distribuzione in esecuzione, quindi salva prima il lavoro.
Dopo averlo riaperto, conferma il gestore prima di toccare l’unità OpenVPN: ps -p 1 -o comm= dovrebbe mostrare systemd. Abilitare systemd non fornisce alcun profilo, alcuna credenziale e alcun nome di istanza, quindi il prossimo errore riguarderà uno di questi elementi e non PID 1.
I container avviano il loro punto di ingresso, non le unit
Un container normale avvia ciò che specifica il suo punto di ingresso o il suo comando, e non è una macchina avviata con systemd, qualunque pacchetto tu installi. Aggiungere systemctl all’immagine ti dà un client senza nulla a cui connettersi. Per Community OpenVPN il modello supportato è di solito un processo in primo piano, openvpn --config /path/to/client.conf, avviato dal punto di ingresso e supervisionato dall’esterno. Quel proprietario gestisce avvio, segnali e arresto, e dovrebbe essere l’unica cosa che gestisce il tunnel.
Non avviare mai una copia interattiva accanto a un punto di ingresso che già gestisce quel tunnel, perché due processi si contenderanno il dispositivo e le rotte. Un processo init minimo nel container raccoglie i figli e inoltra i segnali; non trasforma l’immagine in un host con unit.
Se un deployment ha davvero bisogno di systemd dentro un container, serve un’immagine progettata apposta per questo, non privilegi aggiuntivi aggiunti finché systemctl non smette di lamentarsi.
Leggi l’errore successivo quando il gestore esiste
Non appena un vero gestore avvia il servizio, iniziano gli errori utili. Un errore di permessi sul dispositivo, un errore di analisi della configurazione, una credenziale mancante e un peer irraggiungibile sono quattro problemi diversi che il messaggio su PID 1 non ha mai testato. Leggili nell’ordine in cui l’unità li ha prodotti, usando journalctl -u openvpn-client@office -n 50 su un host systemd, oppure avviando il client in primo piano dove non esiste alcun gestore. L’esecuzione in primo piano è anche il modo più rapido per confermare che il profilo stesso funziona.
Tieni separati i due ambienti nelle tue note: l’host che esegue il tunnel e il posto in cui digiti i comandi.