nordvpn meldet, der Daemon sei nicht erreichbar: Socket, Gruppe oder Unit?

nordvpn auszuführen und eine Meldung über einen nicht erreichbaren Daemon zu bekommen, ist eine enge Beschwerde, die meist dann kommt, wenn Sie ohnehin schon spät dran sind. Sie sagt nichts darüber, ob der Tunnel funktioniert, denn die CLI ist nur ein Frontend: Sie spricht über einen Unix-Socket mit einem Hintergrundprozess, und die Meldung bedeutet, dass dieses Gespräch nicht stattgefunden hat. Gehen Sie von dem Befehl nach außen und halten Sie bei der ersten Sache an, die sich als falsch erweist.

Beginnen Sie dort, wo der Fehler auftaucht

Es sind zwei Prozesse beteiligt, und gerade ihre Verwechslung macht die Sache rätselhaft. Der Daemon besitzt den Tunnel und lauscht auf einem Socket unter /run/nordvpn/. Der Befehl, den Sie eingegeben haben, verbindet sich mit diesem Socket, statt selbst Schnittstellen anzufassen.

Fehlt der Socket oder verweigert er die Verbindung, hat die CLI niemanden zu fragen, also meldet sie die Variante „Benutzer-Daemon“ oder „System-Daemon“ derselben Beschwerde. Eine dieser Varianten nennt den Pfad direkt, und das ist der nützlichste Satz des ganzen Austauschs.

Prüfen Sie zuerst die Unit

Fragen Sie den Dienstmanager, ob der Daemon läuft, und starten und aktivieren Sie ihn dann in einem Schritt, falls nicht:

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

Existiert die Unit, ist aber inaktiv, startet enable --now sie und richtet zugleich den nächsten Boot ein. Existiert die Unit nicht, ist das Paket nicht das, das Sie annehmen, und der installierte Name zählt mehr als der Name in Ihren Notizen. Das klingt nach einer pedantischen Unterscheidung, bis Sie zwanzig Minuten damit verbringen, einen Dienst zu aktivieren, der unter dieser Bezeichnung nie installiert wurde. Lesen Sie, was vorhanden ist, und handeln Sie danach.

Das Auflisten der Unit-Dateien klärt das mit einem Befehl, und es lohnt sich, bevor Sie irgendetwas über die Installation schließen:

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

Veröffentlichungen haben den Dienst unter mehr als einem Unit-Namen ausgeliefert, ein Build, der nordvpn statt nordvpnd verwendet, erzeugt also eine perfekte Kopie dieses Fehlers, während direkt daneben ein gesunder Dienst läuft.

Der Socket und seine Gruppe entscheiden über den Zugriff

Selbst mit laufendem Daemon kann die Verbindung an Berechtigungen scheitern. Der Installer legt eine nordvpn-Gruppe an, und der Socket wird entsprechend besessen, ein Benutzer außerhalb dieser Gruppe wird also abgewiesen, während der Dienst völlig gesund ist.

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

Die Gruppenmitgliedschaft wird beim Sitzungsstart gelesen, deshalb scheint die Änderung in dem Terminal nicht zu wirken, in dem Sie sie vorgenommen haben. Eine neue Login-Shell oder newgrp ist nötig, bevor die laufende Sitzung die neue Gruppe sieht. Testen Sie in einer neuen Shell, nicht in der, die den Befehl gerade ausgeführt hat. Sonst schließen Sie, die Korrektur sei gescheitert, obwohl sie nur noch nicht angewendet wurde.

Der Besitz des Sockets selbst ist die zweite Hälfte dieser Prüfung. Vergleichen Sie die Gruppe am Socket mit den Gruppen, die die Shell meldet, in der die CLI läuft, und die Berechtigungsfrage ist in einem Schritt beantwortet statt durch Neuinstallieren:

ls -l /run/nordvpn
id

Ein laufender Prozess ist kein Beweis für den richtigen Socket. Ein von einem anderen Manager gestarteter Daemon oder ein altes Paket, das einen anders benannten Socket gebunden hat, meldet identisch. Die Verzeichnisauflistung unterscheidet diese Fälle in einer Zeile, deshalb schlägt sie die Neuinstallation.

Der Prozess pro Benutzer bei älterer Paketierung

Manche Paketierung startet einen zweiten Prozess im Kontext des angemeldeten Benutzers, den die Desktop-Integration erwartet. Startet ein System-Init-Skript ihn, ohne zu diesem Konto zu wechseln, sucht die CLI einen Daemon, den keine Sitzung besitzt.

Bei einem Init ohne systemd teilt die dokumentierte Anordnung die Rollen: Der Systemdienst läuft unter einem Namen, der benutzerseitige Prozess unter dem Zielkonto mit chpst -u <user>. Prüfen Sie, welche Anordnung Ihre Installation tatsächlich nutzt, bevor Sie ein Startskript hinzufügen, das die andere voraussetzt.

Woran Sie erkennen, dass Sie fertig sind

Ein Upgrade ist der übliche Auslöser, weil die neue Binärdatei einen Dienstzustand erwartet, den die alte nie hinterlassen hat. Stoppen, erneutes Aktivieren und Starten in dieser Reihenfolge räumt das auf:

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

Der letzte Befehl ist der Abnahmetest. Eine ausgegebene Version bedeutet, dass der Socket antwortet, was jeden verbleibenden Fehler in die Bereiche Anmeldung, Tarif oder Konnektivität verschiebt und aus diesem Artikel herausholt. Antwortet er, hören Sie hier auf zu lesen und sehen Sie stattdessen das Konto an.

Fehlt der Socket weiterhin, lesen Sie das Unit-Journal, um zu sehen, warum er beendet wurde, und prüfen Sie dann, ob /run/nordvpn existiert und ob das Dienstkonto dort schreiben kann. Ein Prozess, der hochkommt und sofort stirbt, hält seinen Grund in diesem Journal fest, und eine Zeile ist schneller zu lesen, als eine Neuinstallation durchzuführen ist.