लेखक न तोडता 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 मधील लपलेल्या नियमाचे नाही, आणि कोणत्याही लॉग व्यवस्थेने चालू बोगदा पुन्हा सुरू करण्याचे कारण होऊ नये।