nordvpn spune că nu ajunge la daemon: socket, grup sau unit?

Rularea nordvpn și primirea unui mesaj despre un daemon inaccesibil este o plângere îngustă care sosește de obicei când ești deja în întârziere. Nu spune nimic despre dacă tunelul funcționează, pentru că CLI-ul este doar o fațadă: vorbește cu un proces din fundal printr-un socket Unix, iar mesajul înseamnă că acea conversație nu a avut loc. Pornește de la comandă spre exterior și oprește-te la primul lucru care se dovedește fals.

Începe de unde apare eroarea

Sunt implicate două procese, și confundarea lor este ceea ce face lucrul acesta misterios. Daemonul deține tunelul și ascultă pe un socket sub /run/nordvpn/. Comanda pe care ai tastat-o se conectează la acel socket în loc să atingă singură interfețele.

Când socketul lipsește sau refuză conexiunea, CLI-ul nu are pe nimeni să întrebe, așa că raportează varianta «daemon de utilizator» sau «daemon de sistem» a aceleiași plângeri. Una dintre aceste variante numește calea direct, și aceasta este cea mai utilă propoziție din toată conversația.

Verifică unit-ul înainte de orice altceva

Întreabă managerul de servicii dacă daemonul rulează, apoi pornește-l și activează-l într-un singur pas dacă nu rulează:

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

Dacă unit-ul există dar este inactiv, enable --now îl pornește și pregătește următoarea bootare în același timp. Dacă unit-ul nu există, pachetul nu este cel pe care îl presupui, iar numele instalat contează mai mult decât numele din notele tale. Sună ca o distincție pedantă până când petreci douăzeci de minute activând un serviciu care nu a fost niciodată instalat sub acea etichetă. Citește ce există, apoi acționează în consecință.

Listarea fișierelor de unit rezolvă asta cu o singură comandă, și merită făcută înainte de a trage orice concluzie despre instalare:

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

Versiunile au livrat serviciul sub mai mult de un nume de unit, așa că o compilare care folosește nordvpn în loc de nordvpnd va produce o copie perfectă a acestei erori în timp ce un serviciu sănătos rulează chiar alături.

Socketul și grupul lui decid accesul

Chiar și cu daemonul pornit, conexiunea poate fi refuzată din cauza permisiunilor. Instalatorul creează un grup nordvpn, iar socketul este deținut în consecință, așa că un utilizator din afara acelui grup este refuzat în timp ce serviciul este perfect sănătos.

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

Apartenența la grup este citită la începutul unei sesiuni, de aceea modificarea pare să nu funcționeze în terminalul în care ai făcut-o. Este nevoie de un shell de autentificare nou sau de newgrp înainte ca sesiunea aflată în rulare să vadă noul grup. Testează într-un shell nou, nu în cel care tocmai a executat comanda. Altfel vei concluziona că remedierea a eșuat, când de fapt încă nu a fost aplicată.

Proprietatea socketului în sine este a doua jumătate a acelei verificări. Compară grupul de pe socket cu grupurile raportate în shell-ul care rulează CLI-ul, iar întrebarea despre permisiuni primește răspuns într-un singur pas în loc de reinstalare:

ls -l /run/nordvpn
id

Un proces viu nu este dovada socketului corect. Un daemon pornit de alt manager, sau un pachet vechi care a legat un socket cu alt nume, raportează la fel. Listarea directorului distinge acele cazuri într-o singură linie, de aceea bate reinstalarea.

Procesul pe utilizator în pachetele mai vechi

Unele pachete rulează un al doilea proces în contextul utilizatorului autentificat, pe care integrarea desktop se așteaptă să îl găsească. Dacă un script de init al sistemului îl pornește fără a coborî în acel cont, CLI-ul caută un daemon pe care nicio sesiune nu îl deține.

Pe un init fără systemd, aranjamentul documentat împarte rolurile: serviciul de sistem rulează sub un nume, iar procesul din partea utilizatorului sub contul țintă cu chpst -u <user>. Verifică ce aranjament folosește de fapt instalarea ta înainte de a adăuga un script de pornire care îl presupune pe celălalt.

Cum știi că ai terminat

Actualizarea este declanșatorul obișnuit, pentru că noul binar așteaptă o stare a serviciului pe care cel vechi nu a lăsat-o niciodată. Oprirea, reactivarea și pornirea în această ordine curăță asta:

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

Acea ultimă comandă este testul de acceptare. O versiune afișată înseamnă că socketul răspunde, ceea ce mută orice defecțiune rămasă în teritoriul autentificării, al planului sau al conectivității și o scoate din acest articol. Dacă răspunde, oprește lectura aici și du-te să te uiți la cont.

Dacă socketul încă lipsește, citește jurnalul unit-ului pentru a vedea de ce s-a oprit, apoi verifică dacă /run/nordvpn există și dacă contul serviciului poate scrie acolo. Un proces care se ridică și moare imediat își consemnează motivul în acel jurnal, iar o linie se citește mai repede decât se execută o reinstalare.