systemctl dit que systemd n’est pas PID 1 : et ensuite ?
Le message sur PID 1 concerne l’environnement, pas OpenVPN. Vérifiez ce qui tourne en PID 1, activez systemd là où il est pris en charge, puis lisez la vraie erreur.
Lancer systemctl start openvpn-client@office et recevoir un message indiquant que le système n’a pas été démarré avec systemd ressemble à une panne de service. Ce n’est pas une panne de service du tout : le systemctl que vous avez invoqué ne trouve aucun gestionnaire en cours d’exécution à qui parler, donc rien concernant OpenVPN n’a été examiné. sudo ne crée pas de gestionnaire, et installer un fichier d’unité n’en crée pas non plus. La commande et la machine viennent de deux mondes différents, et l’erreur est le seul endroit où cela s’est vu.
Commencez par demander quel processus possède le PID 1 là où la commande s’exécute, car cette réponse détermine si des unités existent du tout.
L’erreur nomme l’environnement, pas OpenVPN
systemctl est un client, pas un gestionnaire. Il se connecte au gestionnaire système via une socket, et quand aucun gestionnaire n’est de l’autre côté, il affiche le message que les gens collent dans les forums. ps -p 1 -o pid=,comm= montre ce qui tourne réellement en PID 1, et la réponse est souvent un shell, une enveloppe init ou le point d’entrée propre au conteneur. Dans cette situation, un fichier d’unité peut être parfaitement valide et n’être jamais lu. Répéter la commande en root ne change que les identifiants du client.
Lisez le message entier avant la première ligne. Une erreur du gestionnaire lui-même, comme une unité manquante ou une condition échouée, signifie que vous en avez atteint un ; cette erreur signifie que non.
WSL : activer systemd est un changement de configuration
WSL a reçu le support de systemd dans des versions ultérieures, mais la fonctionnalité s’active par distribution et uniquement là où la version installée de WSL la prend en charge. wsl --version côté Windows indique ce que vous avez, et le /etc/wsl.conf de la distribution contient [boot] une section avec systemd=true. Modifiez ce fichier sans supprimer les sections déjà présentes, puis redémarrez l’instance WSL pour que le changement prenne effet. wsl --shutdown arrête toutes les distributions en cours d’exécution, alors enregistrez votre travail d’abord.
Après la réouverture, confirmez le gestionnaire avant de toucher à l’unité OpenVPN : ps -p 1 -o comm= devrait afficher systemd. Activer systemd ne fournit ni profil, ni identifiant, ni nom d’instance, donc la prochaine erreur concernera l’un de ces éléments et non PID 1.
Les conteneurs lancent leur point d’entrée, pas des unités
Un conteneur normal démarre ce que son point d’entrée ou sa commande spécifie, et ce n’est pas une machine démarrée avec systemd, quels que soient les paquets que vous installez. Ajouter systemctl à l’image vous donne un client sans rien à quoi se connecter. Pour Community OpenVPN, le modèle pris en charge est généralement un processus au premier plan, openvpn --config /path/to/client.conf, lancé par le point d’entrée et supervisé de l’extérieur. Ce propriétaire gère le démarrage, les signaux et l’arrêt, et il devrait être la seule chose à administrer le tunnel.
Ne lancez jamais une copie interactive à côté d’un point d’entrée qui gère déjà ce tunnel, car deux processus vont se disputer le périphérique et les routes. Un processus init minimal dans le conteneur récolte les enfants et transmet les signaux ; il ne transforme pas l’image en hôte doté d’unités.
Si un déploiement a réellement besoin de systemd dans un conteneur, il lui faut une image conçue exprès pour cela, pas des privilèges supplémentaires ajoutés jusqu’à ce que systemctl cesse de se plaindre.
Lisez l’erreur suivante une fois le gestionnaire présent
Dès qu’un vrai gestionnaire lance le service, les erreurs utiles commencent. Un échec de permission de périphérique, une erreur d’analyse de configuration, un identifiant manquant et un pair injoignable sont quatre problèmes différents que le message sur PID 1 n’a jamais testés. Lisez-les dans l’ordre où l’unité les a produits, en utilisant journalctl -u openvpn-client@office -n 50 sur un hôte systemd, ou en lançant le client au premier plan là où aucun gestionnaire n’existe. L’exécution au premier plan est aussi le moyen le plus rapide de confirmer que le profil lui-même fonctionne.
Gardez les deux environnements séparés dans vos notes : l’hôte qui fait tourner le tunnel, et l’endroit où vous tapez des commandes.