nordvpn אומר שלא ניתן להגיע לדמון: socket, קבוצה או יחידה?

הרצת nordvpn וקבלת הודעה על דמון שאי אפשר להגיע אליו היא תלונה צרה שמגיעה בדרך כלל כשכבר מאחרים. היא לא אומרת דבר על כך אם המנהרה עובדת, כי ה-CLI הוא רק חזית: הוא מדבר עם תהליך רקע דרך socket של Unix, וההודעה פירושה שהשיחה הזו לא התקיימה. צאו מהפקודה החוצה ועצרו בדבר הראשון שמתברר כשגוי.

התחילו במקום שבו השגיאה מופיעה

שני תהליכים מעורבים כאן, וערבוב ביניהם הוא מה שהופך את זה למסתורי. הדמון מחזיק במנהרה ומאזין על socket תחת /run/nordvpn/. הפקודה שהקלדתם מתחברת לאותו socket במקום לגעת בעצמה בממשקים.

כשה-socket חסר או מסרב לחיבור, ל-CLI אין את מי לשאול, ולכן הוא מדווח על גרסת «דמון משתמש» או «דמון מערכת» של אותה תלונה. אחת מהגרסאות האלה נוקבת בשם הנתיב ישירות, וזה המשפט השימושי ביותר בכל ההחלפה.

בדקו את היחידה לפני כל דבר אחר

שאלו את מנהל השירותים אם הדמון פועל, ואם לא, הפעילו ואפשרו אותו בצעד אחד:

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

אם היחידה קיימת אך אינה פעילה, enable --now גם מפעיל אותה וגם מסדר את האתחול הבא. אם היחידה אינה קיימת, החבילה אינה זו שאתם מניחים, והשם המותקן חשוב יותר מהשם שברשימות שלכם. זה נשמע כמו הבחנה קפדנית מדי עד שאתם מבזבזים עשרים דקות באפשור שירות שמעולם לא הותקן תחת התווית הזו. קראו מה קיים, ואז פעלו לפי זה.

פירוט קובצי היחידה מכריע בכך בפקודה אחת, וכדאי לעשות אותו לפני שמסיקים משהו על ההתקנה:

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

מהדורות סיפקו את השירות תחת יותר משם יחידה אחד, ולכן בנייה שמשתמשת ב-nordvpn ולא ב-nordvpnd תייצר עותק מושלם של השגיאה הזו בזמן ששירות בריא פועל ממש לצדו.

ה-socket והקבוצה שלו מחליטים על הגישה

גם כשהדמון פועל, החיבור יכול להידחות בגלל הרשאות. המתקין יוצר קבוצת nordvpn, וה-socket הוא בבעלות בהתאם, ולכן משתמש מחוץ לאותה קבוצה נדחה בזמן שהשירות בריא לחלוטין.

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

חברות בקבוצה נקראת כשמתחיל מושב, ולכן נראה שהשינוי לא עובד במסוף שבו עשיתם אותו. נדרש shell התחברות חדש או newgrp לפני שהמושב הפעיל רואה את הקבוצה החדשה. בדקו ב-shell חדש, לא בזה שהריץ זה עתה את הפקודה. אחרת תסיקו שהתיקון נכשל כשבעצם הוא פשוט טרם הוחל.

הבעלות על ה-socket עצמו היא החצי השני של הבדיקה הזו. השוו את הקבוצה על ה-socket לקבוצות שמדווח ה-shell שמריץ את ה-CLI, ושאלת ההרשאות נענית בצעד אחד במקום בהתקנה מחדש:

ls -l /run/nordvpn
id

תהליך חי אינו הוכחה ל-socket הנכון. דמון שהופעל על ידי מנהל אחר, או חבילה ישנה שקישרה socket בשם אחר, מדווחים באותו אופן. פירוט הספרייה מבחין בין המקרים האלה בשורה אחת, ולכן הוא עדיף על התקנה מחדש.

התהליך לכל משתמש באריזה הישנה

חלק מהאריזות מריצות תהליך שני בהקשר של המשתמש המחובר, שאינטגרציית שולחן העבודה מצפה למצוא. אם סקריפט אתחול של המערכת מפעיל אותו בלי לרדת לאותו חשבון, ה-CLI מחפש דמון שאף מושב אינו מחזיק בו.

ב-init שאינו systemd, הסידור המתועד מחלק את התפקידים: שירות המערכת רץ תחת שם אחד והתהליך בצד המשתמש תחת חשבון היעד עם chpst -u <user>. בדקו איזה סידור ההתקנה שלכם באמת משתמשת בו לפני שתוסיפו סקריפט אתחול שמניח את האחר.

איך לדעת שסיימתם

שדרוג הוא הטריגר הרגיל, כי הקובץ הבינארי החדש מצפה למצב שירות שהקודם מעולם לא השאיר. עצירה, אפשור מחדש והפעלה בסדר הזה מנקים אותו:

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

הפקודה האחרונה היא מבחן הקבלה. גרסה מודפסת פירושה שה-socket עונה, מה שמעביר כל תקלה שנותרה לתחום ההתחברות, התוכנית או הקישוריות ומוציא אותה מהמאמר הזה. אם הוא עונה, הפסיקו לקרוא כאן ולכו להסתכל על החשבון במקום.

אם ה-socket עדיין חסר, קראו את יומן היחידה כדי לראות למה היא הסתיימה, ואז בדקו ש-/run/nordvpn קיים וחשבון השירות יכול לכתוב שם. תהליך שעולה ומת מיד רושם את הסיבה שלו ביומן הזה, ושורה אחת מהירה יותר לקריאה מאשר התקנה מחדש לביצוע.