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