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 सर्व्हर नसून सुरुवातीच्या क्रमाचा दोष आहे, आणि त्या दोन्हींना वेगळ्या दुरुस्त्या लागतात। नंतर सेवा पुन्हा सुरू करण्याऐवजी थंड बूटने संपूर्ण गोष्ट सिद्ध करा, कारण पुन्हा सुरू करणे आधीच वर असलेल्या नेटवर्कविरुद्ध चालते आणि तुम्ही माग लावत असलेला दोष नेमका लपवेल। लिंक जाणूनबुजून हळू ठेवून ते पुन्हा करा, आणि जे युनिट केवळ वेगवान नेटवर्कवर चालते त्याला अजूनही तुटलेले माना।