nordvpn indique qu’il n’atteint pas le démon : socket, groupe ou unité ?

Lancer nordvpn et recevoir un message sur un démon injoignable est une plainte étroite qui arrive en général quand vous êtes déjà en retard. Elle ne dit rien de l’état du tunnel, car la CLI n’est qu’une façade : elle parle à un processus d’arrière-plan par une socket Unix, et le message signifie que cette conversation n’a pas eu lieu. Partez de la commande et avancez vers l’extérieur, en vous arrêtant à la première chose qui se révèle fausse.

Commencez là où l’erreur apparaît

Deux processus sont en jeu, et c’est les confondre qui rend l’affaire mystérieuse. Le démon possède le tunnel et écoute sur une socket sous /run/nordvpn/. La commande que vous avez tapée se connecte à cette socket au lieu de toucher elle-même les interfaces.

Quand la socket manque ou refuse la connexion, la CLI n’a personne à interroger, elle signale donc la variante « démon utilisateur » ou « démon système » de la même plainte. L’une de ces variantes nomme le chemin directement, et c’est la phrase la plus utile de tout l’échange.

Vérifiez l’unité avant tout le reste

Demandez au gestionnaire de services si le démon tourne, puis démarrez-le et activez-le en une seule étape s’il ne tourne pas :

systemctl status nordvpnd
sudo systemctl enable --now nordvpnd
nordvpn version

Si l’unité existe mais est inactive, enable --now la démarre et prépare aussi le prochain démarrage. Si l’unité n’existe pas, le paquet n’est pas celui que vous supposez, et le nom installé compte plus que le nom de vos notes. Cela semble une distinction pédante jusqu’à ce que vous passiez vingt minutes à activer un service qui n’a jamais été installé sous cette étiquette. Lisez ce qui est présent, puis agissez en conséquence.

Lister les fichiers d’unité règle cela en une commande, et cela vaut la peine avant de conclure quoi que ce soit sur l’installation :

systemctl list-unit-files 'nordvpn*'
service --status-all

Les versions ont livré le service sous plus d’un nom d’unité, donc une compilation qui utilise nordvpn plutôt que nordvpnd produira une copie parfaite de cette erreur pendant qu’un service sain tourne juste à côté.

La socket et son groupe décident de l’accès

Même avec le démon en marche, la connexion peut être refusée pour des raisons de permissions. L’installateur crée un groupe nordvpn, et la socket appartient en conséquence, donc un utilisateur hors de ce groupe est refusé alors que le service est parfaitement sain.

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

L’appartenance au groupe est lue au démarrage d’une session, et c’est pourquoi le changement semble ne pas fonctionner dans le terminal où vous l’avez fait. Un nouveau shell de connexion ou newgrp est nécessaire avant que la session en cours voie le nouveau groupe. Testez dans un nouveau shell, pas dans celui qui vient d’exécuter la commande. Sinon vous conclurez que le correctif a échoué alors qu’il n’a simplement pas encore été appliqué.

La propriété de la socket elle-même est la seconde moitié de ce contrôle. Comparez le groupe de la socket avec les groupes rapportés dans le shell qui exécute la CLI, et la question des permissions est réglée en une étape plutôt qu’en réinstallant :

ls -l /run/nordvpn
id

Un processus vivant ne prouve pas que la socket est la bonne. Un démon lancé par un autre gestionnaire, ou un ancien paquet qui a lié une socket au nom différent, rapportent la même chose. Le listing du répertoire distingue ces cas en une ligne, et c’est pourquoi il vaut mieux que la réinstallation.

Le processus par utilisateur sur les anciens paquets

Certains paquets lancent un second processus dans le contexte de l’utilisateur connecté, que l’intégration de bureau s’attend à trouver. Si un script d’init du système le lance sans passer à ce compte, la CLI cherche un démon qu’aucune session ne possède.

Sur un init sans systemd, la disposition documentée sépare les rôles : le service système tourne sous un nom et le processus côté utilisateur sous le compte cible avec chpst -u <user>. Vérifiez quelle disposition votre installation utilise réellement avant d’ajouter un script de démarrage qui présuppose l’autre.

Comment savoir que vous avez terminé

La mise à niveau est le déclencheur habituel, car le nouveau binaire attend un état de service que l’ancien n’a jamais laissé. Arrêter, réactiver puis démarrer dans cet ordre nettoie cela :

sudo systemctl stop nordvpnd
sudo systemctl enable --now nordvpnd
sudo systemctl start nordvpnd
nordvpn version

Cette dernière commande est le test d’acceptation. Une version affichée signifie que la socket répond, ce qui déplace toute panne restante vers la connexion, l’offre ou la connectivité et la sort de cet article. Si elle répond, arrêtez de lire ici et allez plutôt regarder le compte.

Si la socket manque toujours, lisez le journal de l’unité pour voir pourquoi elle s’est arrêtée, puis vérifiez que /run/nordvpn existe et que le compte de service peut y écrire. Un processus qui monte et meurt aussitôt consigne sa raison dans ce journal, et une ligne se lit plus vite qu’une réinstallation ne s’exécute.