લેખકને તોડ્યા વિના 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 ની અંદર છુપાયેલો નિયમ નહીં, અને કોઈ પણ લોગ ગોઠવણ કાર્યરત ટનલ ફરી શરૂ કરવાનું કારણ ન બનવું જોઈએ.