कोही भन्छन् कि स्क्रिन अँध्यारो हुँदा VPN मर्‍यो, तब पहिलो उपयोगी प्रश्न यो हो कि तीनमध्ये कुन घटना साँच्चै भयो: सत्र लक भयो, प्यानल बन्द भयो, कि पूरै मेसिन सुत्यो। यी फरक टाइमरका फरक संयन्त्र हुन्, र तीमध्ये एउटाले मात्र प्रक्रियाको तालिका बनाउन पूर्ण रूपमा रोक्न सक्छ। तलका जाँचहरू क्रममा गर्नुहोस्। प्रश्नको जवाफ दिने पहिलो जाँचमा रोकिनुहोस्, किनकि त्यसपछिको हरेक जाँच अरू कुराको जवाफ दिन्छ।

पहिलो जाँच: लक, ब्ल्याङ्क र निद्रा छुट्याउनुहोस्

लकले सत्र कसले प्रयोग गर्न पाउने भन्ने बदल्छ; कम्पोजिटर चित्र बनाउँदै रहन्छ, नेटवर्क स्ट्याक चल्दै रहन्छ र VPN क्लाइन्टलाई केही थाहा हुँदैन। स्क्रिन ब्ल्याङ्क हुँदा निष्क्रिय अवधिपछि प्यानल बन्द हुन्छ र मेसिन पूर्ण जागा रहन्छ। सस्पेन्डले प्रोसेसर रोक्छ, अर्थात् प्रयोगकर्ता-स्थानको कुनै पनि प्रक्रिया तालिकाबद्ध हुँदैन, त्यसैले अन्तराल जतिसुकै छोटो राख्नुहोस्, कुनै कीपअलाइभ चल्न सक्दैन।

EventWhat it stopsCan it kill the tunnel?
Session lockInput to your sessionNo
Display blankThe panelNo
Suspend to RAMCPU scheduling, hence every processYes, and silently
HibernateEverything, with state written to diskYes

यही तालिका कारण हो कि «स्क्रिन अँध्यारो भयो» निदान होइन। पाँच मिनेटमा ब्ल्याङ्क र तीस मिनेटमा सस्पेन्डमा सेट गरिएको डेस्कटप छैटौँ मिनेटमा पूर्ण स्वस्थ टनेलसहित अँध्यारो स्क्रिन देखाउनेछ। तीसौँ मिनेटको खराबी अर्को घटना र अर्को उपाय हो, र कोठाको अर्को छेउबाट दुवै एउटै देखिन्छन्।

दोस्रो जाँच: ऊर्जा र नेटवर्कका घटनाहरू एउटै समयरेखामा राख्नुहोस्

पूरै बुटको सट्टा सीमित अवधिको जर्नल पढ्नुहोस्, र लगइन प्रबन्धक तथा जडानको मालिक दुवै समावेश गर्नुहोस्:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

पहिलो आदेशले निद्राका अनुरोध, फेरि जाग्ने र त्यसपछिका नेटवर्क परिवर्तन देखाउँछ। दोस्रोले अहिले केले अवरोधक ताला समातेको छ देखाउँछ, जसले तपाईंलाई कुनै कुराले जानाजान निद्रा रोकिरहेको छ कि छैन र त्यो कुन प्रोग्राम हो भन्ने बताउँछ। तपाईंको जडानको मालिक NetworkManager नभए युनिटका नाम मिलाउनुहोस्, र अर्को प्रयोगकर्ताको युनिट वा प्रणाली जर्नल पढ्नु स्थानीय नीतिमा निर्भर हुन्छ भन्ने सम्झनुहोस्।

हराएको लाइन नकारात्मक नतिजा होइन। छानिएको युनिटको जर्नल तपाईंको खातालाई देखिँदैन भने, सस्पेन्ड रेकर्डको अनुपस्थितिले केही प्रमाणित गर्दैन, र खाली फिल्टरबाट «यो कहिल्यै सुतेन» भन्ने निष्कर्ष निकाल्नु त्यही बाटो हो जसमा मानिसहरू एक हप्ता कीपअलाइभ मिलाउँदै बिताउँछन्।

तेस्रो जाँच: यदि यो सुत्यो भने, यो जानाजान थियो कि भनेर निर्णय गर्नुहोस्

समयरेखामा निद्राको परिवर्तन देखिनासाथ प्रश्न «VPN किन भाँचियो» बाट «मेसिनलाई सुत्नु नै पर्ने थियो कि» मा बदलिन्छ। ल्यापटपमा जवाफ प्रायः हो हो, र टनेलको काटिनु अपेक्षित व्यवहार हो जसबाट क्लाइन्टले जाग्दा सुधार्नुपर्छ। पहुँचयोग्य रहनुपर्ने वर्कस्टेशनमा निद्राको नीति नै बदल्नुपर्ने कुरा हो। यी दुई मेसिनमध्ये कुनलाई हेरिरहनुभएको छ भन्ने निर्णय गर्न एउटा प्रश्न चाहिन्छ, र त्यो यस्तो प्रश्न होइन जसको जवाफ जर्नलले तपाईंको तर्फबाट दिन सक्छ।

यसलाई लगइन गरिएको सत्रका नियन्त्रणहरूबाट बदल्नुहोस्, वा आवश्यकता पूरै मेसिनको भए प्रशासक-समर्थित संयन्त्रबाट बदल्नुहोस्। अर्को खाताबाट लगइन गरिरहेको बेला डिस्प्ले प्रबन्धकको सेटिङ सम्पादन गर्नु त्यही कार्य होइन र अर्को सत्र सुरु नहुँदासम्म काम गरेजस्तो देखिन्छ। ऊर्जा व्यवस्थापन पूर्ण रूपमा बन्द गर्नु ब्याट्रीको आयु खाने र वास्तविक नीति प्रश्न लुकाउने फराकिलो पहिलो प्रतिक्रिया हो।

चौथो जाँच: यदि यो जागै रह्यो भने, नेटवर्क र क्लाइन्ट हेर्नुहोस्

टनेल गुमाएको जागा मेसिनसँग तीनमध्ये एउटा कथा हुन्छ: पहुँच नेटवर्क ढल्यो, VPN क्लाइन्ट रोकियो वा फेरि सुरु भयो, वा सर्भर पक्षले सम्बन्धको म्याद सकायो तर क्लाइन्ट अझै जोडिएको छ भन्ने विश्वास गरिरह्यो। आधारभूत लिंक घटनाको टाइमस्ट्याम्पलाई टनेल घटनासँग तुलना गर्नुहोस्, र कुन पहिले आयो भन्नेमा सटीक रहनुहोस्।

त्यसपछि मूल सत्रबाट अलगै पुनर्प्राप्तिको बाटो जाँच्नुहोस्। पुनर्प्राप्त टनेलबाट नयाँ अनुरोध सफल हुन सक्छ, तर काटिनुअघि खोलिएको दीर्घकालीन अनुप्रयोग सत्र भाँचिएकै रहन्छ, किनकि अनुप्रयोगले पुरानो सकेट वा क्यास गरिएको ठेगाना समातिरहेको हुन्छ। यो अनुप्रयोगको समस्या हो, टनेल फर्किएन भन्ने प्रमाण होइन।

उपयोगी प्रतिवेदनमा के हुन्छ

क्रम टाइमस्ट्याम्प र मालिकसहित लेख्नुहोस्: सत्र कहिले लक भयो, स्क्रिन कहिले अँध्यारो भयो, निद्राको अनुरोध रेकर्ड भयो कि भएन, लिंक कहिले ढल्यो र फर्कियो, टनेलले कहिले अवस्था बदल्यो र अनुप्रयोगले वास्तवमा के गर्‍यो। हरेक बुँदाको मालिक हुन्छ, त्यसैले हरेक बुँदा Linux बारेको सामान्य गुनासो बन्नुको सट्टा सही व्यक्तिलाई दिन सकिन्छ।

यीमध्ये कुनै लाइन हराएको भए, त्यो मापन गर्नुपर्ने अर्को कुरा हो, बदल्नुपर्ने अर्को कुरा होइन। खाली ठाउँ भएको समयरेखा अनुमानमा गरिएको सेटिङ परिवर्तनभन्दा बढी जानकारी दिन्छ।

सम्बन्धित लेखहरू