लेखक को तोड़े बिना VPN वॉचडॉग लॉग घुमाएँ

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

घुमाव नीति से पहले गंतव्य चुनें

जो systemd इकाई पहले से अपना आउटपुट जर्नल में भेजती है, वह प्रतिधारण को एक ही जगह रखती है। journald SystemMaxUse और MaxRetentionSec जैसी सीमाएँ लागू करता है, इसलिए वहाँ लॉग करने वाला वॉचडॉग बिना किसी अतिरिक्त काम के सीमा पा लेता है। उसके बगल में दूसरी असीमित फ़ाइल जोड़ने से बिना लाभ के रखरखाव दोगुना हो जाता है।

समर्पित फ़ाइल तभी अपनी जगह कमाती है जब कोई और उसे पढ़ता है: एक पार्सर, ऑडिट निर्यात, या ऐसा पृष्ठ जो स्थिर पथ की अपेक्षा करता है। वह निर्णय हो जाने के बाद फ़ाइल को मालिक, मोड और घुमाव नीति की ज़रूरत होती है जो साथ लिखी जाएँ, क्योंकि तीनों केवल एक समुच्चय के रूप में सही होते हैं। जो पथ कोई भी बना सकता है वही पथ कोई भी बदल सकता है, इसलिए निर्देशिका की अनुमतियाँ उसी नोट में आती हैं। यह सब जाँच के बगल में लिखें और अगला संपादन उन्हीं तथ्यों से शुरू होगा।

लेखक से मेल खाता खंड लिखें

ऐसे लेखक से शुरू करें जो हर कॉल पर पथ खोलता है, एक पंक्ति जोड़ता है और बाहर निकलता है। वह पैटर्न प्रक्रिया के किसी सहयोग के बिना घुमाव से बच जाता है, क्योंकि अगली बार वही फ़ाइल खुलती है जो उस समय उस पथ पर है। नीचे का खंड एक सप्ताह के संस्करण रखता है और फ़ाइल को उसी मालिक और मोड के साथ फिर बनाता है जो लेखक को चाहिए:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

logrotate पुस्तिका गणना को रखे गए घुमाए संस्करणों की संख्या के रूप में परिभाषित करती है, सात दिन के इतिहास की गारंटी के रूप में नहीं, और daily शब्द का मूल्यांकन कार्य के चलने पर होता है, स्वयं शेड्यूलर की तरह व्यवहार करने के बजाय। अधिकांश वितरणों में systemd टाइमर या cron प्रविष्टि पहले से उस कॉल की मालिक है, इसलिए दूसरी जोड़ने से पहले देखें कि कौन सी मौजूद है। स्वामित्व का मेल होना प्रतिधारण संख्या से अधिक महत्वपूर्ण है। केवल root के मोड को सेवा खाते द्वारा लिखी फ़ाइल पर कॉपी करने से अगले घुमाव पर लॉगिंग रुक जाती है, और विफलता घंटों बाद त्रुटि के रूप में नहीं बल्कि पुराने टाइमस्टैम्प के रूप में दिखती है। कहीं और से खंड कॉपी करने से पहले लेखक के उपयोगकर्ता की पुष्टि करें।

जो लेखक कभी फिर नहीं खोलता उसे दूसरा उपाय चाहिए

लंबे समय तक चलने वाली प्रक्रिया जो खुला विवरणक रखती है, उसका लेखन नाम बदले गए inode में जारी रहता है। जगह मुक्त नहीं होती और दिखने वाली फ़ाइल बढ़ना बंद कर देती है, जो inode जाँचने तक टूटा घुमाव जैसा दिखता है। या तो प्रक्रिया को फिर से खोलना सिखाएँ, या घुमाव को नाम बदलने के बजाय कॉपी और काटने दें।

फिर से खोलने का रास्ता वहाँ अधिक साफ़ है जहाँ सॉफ़्टवेयर उसका समर्थन करता है: दस्तावेज़ी सिग्नल भेजें या दस्तावेज़ी कमांड चलाएँ, और प्रक्रिया को नई फ़ाइल स्वयं खोलने दें। विकल्प copytruncate है, जो सामग्री को घुमाए नाम पर कॉपी करता है और फिर मूल को उसकी जगह काट देता है, इसलिए विवरणक मान्य रहता है पर कॉपी और कटाई के बीच पड़ने वाला लेखन खो जाता है।

systemd द्वारा शुरू की गई इकाइयों के लिए, StandardOutput को जर्नल या फ़ाइल पर इंगित करें और इकाई को जीवनचक्र रखने दें। बिना आकार-सीमा के tee -a के ज़रिए जोड़ने वाला shell लूप वही व्यवस्था है जो किसी व्यवधान में विभाजन भर देती है, क्योंकि विफल जाँच अक्सर स्वस्थ जाँच से बहुत अधिक लॉग करती है।

टाइमर की प्रतीक्षा किए बिना घुमाव जाँचें

डीबग मोड बताता है क्या होगा और कुछ भी नहीं छूता, जो इसे संपादन के बाद पहली सुरक्षित बार चलाने योग्य बनाता है। संतुष्ट होने पर असली घुमाव बाध्य करें, फिर पुष्टि करें कि अगली लॉग पंक्ति नाम बदली फ़ाइल के बजाय नई फ़ाइल में गिरती है:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

आउटपुट उसी क्रम में पढ़ें। डीबग पास को फ़ाइल और अपने इच्छित कार्यों का नाम लेना चाहिए; बाध्य रन को अपेक्षित घुमाया नाम देना चाहिए; tail को लेखक के फिर चलने के बाद नई प्रविष्टि दिखानी चाहिए। बढ़ता df मान और सिकुड़ती दिखने वाली फ़ाइल ऊपर बताई विवरणक समस्या का अर्थ है।

बाध्य रन को दो बार दोहराएँ ताकि दिखे कि संस्करण पहले से होने पर प्रतिधारण कैसे व्यवहार करता है। सबसे पुरानी फ़ाइल हटाना अपेक्षित परिणाम है, और हटाना न होना आम तौर पर बताता है कि घुमाए नाम में संख्या या वाइल्डकार्ड logrotate द्वारा बनाए गए से मेल नहीं खाते।

वापसी और लिखित अभिलेख रखें

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

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

अंत में, लॉग का निर्णय पुनर्प्राप्ति के निर्णय से अलग रखें। विफल जाँच को कनेक्शन की अपनी पुनर्प्राप्ति नीति का पालन करना चाहिए, logrotate के भीतर छिपे नियम का नहीं, और कोई भी लॉग व्यवस्था काम करती सुरंग को फिर से शुरू करने का कारण नहीं होनी चाहिए।