למה יחידת VPN מתחילה לפני הרשת ואז מתה

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

היעד הוא נקודת מפגש, לא מנהל

network-online.target לא יודע מהי רשת. זו נקודת תיאום שאוספת את השירות שאמור לעכב את האתחול עד שהקישור יהיה שמיש, והיא מאצילה את ההגדרה למנהל הרשת ששולט במכונה. ברוב המחשבים השולחניים והשרתים פירושו של דבר שירות המתנה שמסופק על ידי NetworkManager או על ידי systemd-networkd. אם לא תפעילו אף אחד מהם, ליעד אין במה להמתין, ולכן הוא מושלם ברגע שמשהו מושך אותו פנימה, וזה יכול לקרות הרבה לפני ש-DHCP עונה. שורת הסדר ביחידה שלכם הייתה כנה ובכל זאת חסרת תועלת.

השאלה הראשונה היא אפוא לא מה היחידה שלכם מצהירה. אלא אם משהו במכונה הזאת באמת עושה את ההמתנה.

קראו את האתחול האחרון ולא את קובץ היחידה

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

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

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

הוסיפו את ההמתנה, ואז את הניסיון החוזר

השתמשו ב-drop-in במקום לערוך יחידה ארוזה, כדי שעדכון חבילה לא יזרוק את השינוי בשקט. שתי הנחיות חשובות: היחידה חייבת להיות מסודרת אחרי היעד, והיא חייבת למשוך את היעד לאותה טרנזקציה. סדר לבדו לא מזמן את היעד; הרצון עושה זאת.

היחידה הארוזה של לקוח OpenVPN כבר נושאת את שניהם. יחידות שנכתבו ביד נושאות בדרך כלל אחד או כלום, וזה שווה בדיקה לפני שמוסיפים משהו.

[Service]
Restart=on-failure
RestartSec=15

למה שינה קבועה היא מלכודת

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

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

כשהסדר נכון והשמות עדיין נכשלים

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

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