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 भित्र लुकेको नियम होइन, र कुनै पनि लग व्यवस्थाले चलिरहेको सुरुङ फेरि सुरु गर्ने कारण बन्नु हुँदैन।

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