nordvpn säger att daemonen inte nås: socket, grupp eller unit?
Tunneln kan vara helt i ordning; CLI:t har bara tappat sin socket till nordvpnd. Gå från kommandot till uniten, sedan till socketrättigheterna, och stanna vid första felet.
Att köra nordvpn och få ett meddelande om en daemon som inte går att nå är en smal klagan som oftast kommer när du redan är sen. Den säger ingenting om huruvida tunneln fungerar, eftersom CLI:t bara är en front: det talar med en bakgrundsprocess över en Unix-socket, och meddelandet betyder att det samtalet inte ägde rum. Gå utåt från kommandot och stanna vid det första som visar sig vara fel.
Börja där felet dyker upp
Två processer är inblandade, och det är förväxlingen av dem som gör detta mystiskt. Daemonen äger tunneln och lyssnar på en socket under /run/nordvpn/. Kommandot du skrev ansluter till den socketen i stället för att själv röra vid gränssnitten.
När socketen saknas eller vägrar anslutningen har CLI:t ingen att fråga, så det rapporterar användar-daemon- eller system-daemon-varianten av samma klagan. En av dessa varianter namnger sökvägen direkt, och det är den mest användbara meningen i hela utbytet.
Kontrollera uniten före allt annat
Fråga tjänstehanteraren om daemonen körs, och starta och aktivera den sedan i ett steg om den inte gör det:
systemctl status nordvpnd
sudo systemctl enable --now nordvpnd
nordvpn version
Om uniten finns men är inaktiv startar enable --now den och ordnar nästa uppstart samtidigt. Om uniten inte finns är paketet inte det du antar, och det installerade namnet betyder mer än namnet i dina anteckningar. Det låter som en pedantisk skillnad tills du lägger tjugo minuter på att aktivera en tjänst som aldrig installerades under den etiketten. Läs vad som finns och agera efter det.
Att lista unitfilerna avgör det med ett enda kommando, och det är värt att göra innan du drar någon slutsats om installationen:
systemctl list-unit-files 'nordvpn*'
service --status-all
Utgåvor har levererat tjänsten under mer än ett unitnamn, så ett bygge som använder nordvpn i stället för nordvpnd kommer att producera en perfekt kopia av detta fel medan en frisk tjänst kör precis bredvid.
Socketen och dess grupp avgör åtkomsten
Även med daemonen igång kan anslutningen nekas på grund av rättigheter. Installatören skapar en nordvpn-grupp, och socketen ägs i enlighet med det, så en användare utanför den gruppen nekas medan tjänsten är helt frisk.
sudo usermod -aG nordvpn "$USER"
newgrp nordvpn
Gruppmedlemskap läses när en session börjar, och därför verkar ändringen inte fungera i terminalen där du gjorde den. Ett nytt inloggningsskal eller newgrp krävs innan den körande sessionen ser den nya gruppen. Testa i ett nytt skal, inte i det som just körde kommandot. Annars drar du slutsatsen att rättelsen misslyckades när den bara inte har tillämpats än.
Ägandet av själva socketen är den andra halvan av den kontrollen. Jämför gruppen på socketen med de grupper som skalet som kör CLI:t rapporterar, och rättighetsfrågan besvaras i ett steg i stället för genom ominstallation:
ls -l /run/nordvpn
id
En levande process är inte bevis på rätt socket. En daemon som startats av en annan hanterare, eller ett gammalt paket som band en annorlunda namngiven socket, rapporterar identiskt. Kataloglistningen skiljer de fallen på en rad, och därför slår den ominstallation.
Processen per användare på äldre paketering
Viss paketering kör en andra process i den inloggade användarens kontext, som skrivbordsintegrationen förväntar sig att hitta. Om ett system-init-skript startar den utan att gå ned till det kontot letar CLI:t efter en daemon som ingen session äger.
På ett init utan systemd delar den dokumenterade ordningen rollerna: systemtjänsten körs under ett namn och processen på användarsidan under målkontot med chpst -u <user>. Kontrollera vilken ordning din installation faktiskt använder innan du lägger till ett startskript som förutsätter den andra.
Hur du vet att du är klar
En uppgradering är den vanliga utlösaren, eftersom den nya binärfilen förväntar sig ett tjänstetillstånd som den gamla aldrig lämnade. Stoppa, återaktivera och starta i den ordningen rensar det:
sudo systemctl stop nordvpnd
sudo systemctl enable --now nordvpnd
sudo systemctl start nordvpnd
nordvpn version
Det sista kommandot är acceptanstestet. En utskriven version betyder att socketen svarar, vilket flyttar varje kvarvarande fel till området för inloggning, plan eller anslutning och ut ur den här artikeln. Om den svarar, sluta läsa här och gå och titta på kontot i stället.
Om socketen fortfarande saknas, läs unitens journal för att se varför den avslutades, och kontrollera sedan att /run/nordvpn finns och att tjänstekontot kan skriva där. En process som reser sig och dör direkt registrerar sitt skäl i den journalen, och en rad är snabbare att läsa än en ominstallation är att utföra.