എഴുത്തുകാരനെ തകർക്കാതെ 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-നുള്ളിൽ ഒളിച്ചിരിക്കുന്ന ഒരു നിയമമല്ല, കൂടാതെ പ്രവർത്തിക്കുന്ന ടണൽ വീണ്ടും ആരംഭിക്കാനുള്ള കാരണമാകാൻ ഒരു ലോഗ് ക്രമീകരണവും പാടില്ല.