nordvpn zegt de daemon niet te bereiken: socket, groep of unit?

nordvpn draaien en een melding krijgen over een onbereikbare daemon is een smalle klacht die meestal komt wanneer u al te laat bent. Ze zegt niets over of de tunnel werkt, want de CLI is alleen een voorkant: hij praat via een Unix-socket met een achtergrondproces, en de melding betekent dat dat gesprek niet heeft plaatsgevonden. Loop van het commando naar buiten en stop bij het eerste ding dat onwaar blijkt te zijn.

Begin waar de fout verschijnt

Er zijn twee processen bij betrokken, en juist het verwarren daarvan maakt dit mysterieus. De daemon bezit de tunnel en luistert op een socket onder /run/nordvpn/. Het commando dat u typte maakt verbinding met die socket in plaats van zelf de interfaces aan te raken.

Als de socket ontbreekt of de verbinding weigert, heeft de CLI niemand om het te vragen, dus meldt hij de gebruikers-daemon- of systeem-daemon-variant van dezelfde klacht. Een van die varianten noemt het pad direct, en dat is de nuttigste zin van de hele uitwisseling.

Controleer de unit vóór al het andere

Vraag de servicemanager of de daemon draait, en start en activeer hem dan in één stap als dat niet zo is:

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

Als de unit bestaat maar inactief is, start enable --now hem en regelt tegelijk de volgende boot. Als de unit niet bestaat, is het pakket niet het pakket dat u aanneemt, en de geïnstalleerde naam is belangrijker dan de naam in uw notities. Dat klinkt als een pedant onderscheid tot u twintig minuten besteedt aan het activeren van een dienst die nooit onder dat label is geïnstalleerd. Lees wat er is, en handel daarnaar.

Het opsommen van de unitbestanden beslecht dat met één commando, en het is de moeite waard voordat u iets over de installatie concludeert:

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

Releases hebben de dienst onder meer dan één unitnaam geleverd, dus een build die nordvpn in plaats van nordvpnd gebruikt, levert een perfecte kopie van deze fout op terwijl er direct naast een gezonde dienst draait.

De socket en zijn groep beslissen over toegang

Zelfs met een draaiende daemon kan de verbinding op grond van rechten worden geweigerd. De installer maakt een groep nordvpn aan, en de socket is dienovereenkomstig eigendom, dus een gebruiker buiten die groep wordt geweigerd terwijl de dienst volkomen gezond is.

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

Groepslidmaatschap wordt gelezen wanneer een sessie begint, en daarom lijkt de wijziging niet te werken in de terminal waar u hem hebt gemaakt. Een nieuwe inlogshel of newgrp is nodig voordat de draaiende sessie de nieuwe groep ziet. Test in een nieuwe shell, niet in degene die het commando net uitvoerde. Anders concludeert u dat de oplossing faalde terwijl die gewoon nog niet is toegepast.

Het eigendom van de socket zelf is de tweede helft van die controle. Vergelijk de groep op de socket met de groepen die de shell waarin de CLI draait, meldt, en de rechtenvraag is in één stap beantwoord in plaats van door te herinstalleren:

ls -l /run/nordvpn
id

Een levend proces is geen bewijs van de juiste socket. Een daemon die door een andere manager is gestart, of een oud pakket dat een anders genoemde socket bond, meldt hetzelfde. De mapvermelding onderscheidt die gevallen in één regel, en daarom is die beter dan herinstalleren.

Het proces per gebruiker bij oudere verpakking

Sommige verpakkingen draaien een tweede proces in de context van de ingelogde gebruiker, dat de desktopintegratie verwacht te vinden. Als een systeem-init-script het start zonder naar dat account te wisselen, zoekt de CLI een daemon die geen enkele sessie bezit.

Op een init zonder systemd verdeelt de gedocumenteerde opstelling de rollen: de systeemdienst draait onder één naam en het proces aan de gebruikerskant onder het doelaccount met chpst -u <user>. Controleer welke opstelling uw installatie werkelijk gebruikt voordat u een startscript toevoegt dat de andere veronderstelt.

Hoe u weet dat u klaar bent

Een upgrade is de gebruikelijke trigger, omdat het nieuwe binaire bestand een dienststatus verwacht die het oude nooit achterliet. Stoppen, opnieuw activeren en starten in die volgorde ruimt het op:

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

Dat laatste commando is de acceptatietest. Een afgedrukte versie betekent dat de socket antwoordt, wat elke resterende fout naar het terrein van inloggen, abonnement of connectiviteit verplaatst en uit dit artikel haalt. Als hij antwoordt, stop dan hier met lezen en ga in plaats daarvan naar het account kijken.

Als de socket nog steeds ontbreekt, lees dan het unit-journaal om te zien waarom hij stopte, en controleer vervolgens of /run/nordvpn bestaat en of het serviceaccount daar kan schrijven. Een proces dat opkomt en meteen sterft, legt zijn reden vast in dat journaal, en één regel lezen gaat sneller dan een herinstallatie uitvoeren.