openvpn --errors-to-stderr एक लॉन्च विकल्प है, त्रुटि नहीं

जिस कमांड लाइन में --errors-to-stderr है, वह शिकायत जैसा लगता है, पर शिकायत नहीं है। शब्द किसी विकल्प के नाम का हिस्सा है, ठीक वैसे ही जैसे लॉग फ़ाइल का नाम इस बारे में कुछ नहीं बताता कि फ़ाइल में क्या है। कोई भी कॉन्फ़िगरेशन बदलने से पहले यह तय करें कि आप वास्तव में क्या पढ़ रहे हैं।

निर्णय की तीन शाखाएँ हैं: पंक्ति स्वयं लॉन्च है, पंक्ति प्रोग्राम द्वारा छापा गया आउटपुट है, या पंक्ति वह टेक्स्ट है जिसे VPN शुरू होने से पहले किसी रैपर ने दोहराया। हर शाखा देखने के लिए अलग जगह बताती है, और उनमें से केवल एक ही VPN का अपना संदेश है।

विकल्प का नाम स्थिति संदेश नहीं है

Community OpenVPN के लिए --errors-to-stderr त्रुटि आउटपुट को मानक आउटपुट के बजाय मानक त्रुटि पर भेजता है। यह स्ट्रीम का चयन है, गंभीरता का फ़िल्टर नहीं, और यह कोई त्रुटि नहीं बनाता। बाद का --log या --log-append उन्हीं संदेशों को फ़ाइल में भेज सकता है, इसलिए फ़्लैग का प्रभाव बाकी कमांड पर निर्भर करता है। स्रोत से लॉगिंग संदर्भ उसी क्रम को परिभाषित करता है।

इसलिए फ़्लैग की मौजूदगी बताती है कि त्रुटियाँ कहाँ जाएँगी। यह नहीं बताती कि कोई हुई है।

लॉन्च लाइन या प्रक्रिया का आउटपुट

यह पूछकर शुरू करें कि टेक्स्ट किसने छापा। सेवा इकाई, एप्लिकेशन बंडल या शेल रैपर अक्सर VPN प्रक्रिया के कुछ लिखने से पहले पूरा argv दोहराते हैं। यदि आप केवल एक टुकड़ा देखते हैं तो वह प्रतिध्वनि स्थिति पंक्ति से अलग नहीं पहचानी जा सकती।

यदि पंक्ति रैपर से आई है, तो VPN अभी नहीं चला है और उसके पास बताने को कुछ नहीं है। आउटपुट में और नीचे उस पहले संदेश को देखें जिसमें टाइमस्टैम्प या सबसिस्टम का नाम हो।

यदि पंक्ति VPN प्रक्रिया से आई है, तो भी वह केवल आह्वान है। OpenVPN अपनी कमांड लाइन को त्रुटि के रूप में नहीं छापता, और महत्वपूर्ण संदेश उसके बाद आते हैं।

प्रक्रिया और उसका परिणाम खोजें

तय करें कि प्रक्रिया अभी भी चल रही है या नहीं। चल रहा और फिर से प्रयास करने वाला क्लाइंट तुरंत बाहर निकल गए क्लाइंट से बहुत अलग दिखता है, और दोनों के आगे वही कमांड लाइन होती है।

फिर परिणाम उस घटक के माध्यम से पढ़ें जो प्रक्रिया का स्वामी है। systemd के अंतर्गत यह इकाई का जर्नल है; डेस्कटॉप ऐप में यह ऐप का अपना लॉग या कंसोल है। निकास स्थिति और अंतिम संदेश उस प्रश्न का उत्तर देते हैं जिसकी ओर विकल्प का नाम केवल संकेत करता है।

कॉन्फ़िगरेशन पार्स त्रुटि, गुम फ़ाइल, अस्वीकृत क्रेडेंशियल और पीयर टाइमआउट चार अलग घटनाएँ हैं। वे एक ही स्ट्रीम पर आती हैं। उन्हें चार अलग सुधार चाहिए। प्रोफ़ाइल को छूने से पहले तय करें कि आपके पास कौन-सी है, और मदद माँगते समय सटीक संदेश उद्धृत करें।

फ़्लैग कब अपनी जगह का हक़दार है

फ़्लैग तब अपनी जगह का हक़दार है जब stdout डेटा ले जाता है और त्रुटियों को उसे दूषित नहीं करना चाहिए, या जब कोई रैपर दोनों स्ट्रीम अलग-अलग पकड़ता है। टर्मिनल में फ़ोरग्राउंड सत्र में दोनों स्ट्रीम आपके सामने आती हैं। उस स्थिति में यह भेद शायद ही बदलता है कि आप क्या करते हैं।

यदि आसपास की स्क्रिप्ट विभाजन पर निर्भर है तो इसे रखें। नाम भयावह लगता है इसलिए इसे हटाना बदल देता है कि संदेश कहाँ दिखते हैं और बाकी कुछ ठीक नहीं करता।

क्या न बदलें

विकल्प को मरम्मत के चरण के रूप में न लें। इसे हटाना प्रमाणपत्र, रूट या प्रमाणीकरण विफलता ठीक नहीं कर सकता।

यदि आह्वान में --config stdin है, तो कॉन्फ़िगरेशन मानक इनपुट के माध्यम से दिया जा रहा है। फ़ाइल कैसे उपलब्ध कराई जाती है, यह उस पर एक अलग निर्णय है। एक बार में एक चीज़ बदलें, और दूसरी बदलने से पहले वास्तविक संदेश फिर से पढ़ें।