Sukti VPN sargybinio žurnalą nesulaužant rašančiojo proceso

VPN būsenos patikra, kas minutę prirašanti po vieną eilutę, tyliai sukuria antrą pareigą: nuspręsti, kaip tos eilutės palieka diską. Tunelio taisymas šiai pareigai nieko neduoda, o failo pervadinimas neperadresuoja proceso, kuris vis dar laiko seną aprašą. Pirmiausia atsakykite į paskirties vietos klausimą, tada suderinkite sukimą su tuo, kaip rašantysis procesas jį atidaro.

Pasirinkite paskirties vietą prieš sukimo politiką

systemd padalinys, jau siunčiantis savo išvestį į žurnalą, saugojimą laiko vienoje vietoje. journald taiko ribas, tokias kaip SystemMaxUse ir MaxRetentionSec , todėl ten registruojantis sargybinis paveldi ribą be jokio papildomo darbo. Antro neriboto failo įdėjimas greta padvigubina priežiūrą be naudos.

Atskiras failas užsitarnauja savo vietą, kai jį skaito kažkas kitas: analizatorius, audito eksportas ar puslapis, tikintis stabilaus kelio. Priėmus tą sprendimą, failui reikia savininko, režimo ir sukimo politikos, užrašytų kartu, nes visi trys teisingi tik kaip rinkinys. Kelias, kurį gali sukurti bet kas, yra ir kelias, kurį gali pakeisti bet kas, todėl katalogo teisės priklauso tai pačiai pastabai. Užrašykite visa tai šalia patikros ir kitas keitimas prasidės nuo tų pačių faktų.

Rašykite bloką pagal rašantįjį procesą

Pradėkite nuo rašančiojo proceso, kuris kiekvieno kvietimo metu atidaro kelią, prirašo eilutę ir išeina. Šis šablonas išgyvena sukimą be jokio proceso bendradarbiavimo, nes kitas paleidimas atidaro tą failą, kuris šiuo metu yra tame kelyje. Toliau pateiktas blokas saugo savaitę versijų ir iš naujo sukuria failą su savininku ir režimu, kurių reikia rašančiajam procesui:

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

logrotate vadovas apibrėžia skaičių kaip saugomų pasuktų versijų skaičių, o ne kaip garantuotą septynių dienų istoriją, o raktinis žodis daily įvertinamas, kai užduotis vykdoma, o ne veikia kaip savas planuotojas. Daugumoje distribucijų systemd laikmatis ar cron įrašas jau valdo tą kvietimą, todėl patikrinkite, kuris egzistuoja, prieš pridėdami antrą. Savininko sutapimas svarbesnis už saugojimo skaičių. Tik root skirtą režimą nukopijavus į failą, kurį rašo paslaugos paskyra, registravimas sustoja kitą kartą sukant, o gedimas pasirodo po kelių valandų kaip pasenęs laiko žymuo, o ne kaip klaida. Patvirtinkite rašančiojo proceso naudotoją prieš kopijuodami bloką iš kitur.

Procesas, kuris niekada vėl neatidaro, reikalauja kito sprendimo

Ilgai veikiantis procesas, laikantis atvirą aprašą, toliau rašo į pervadintą inode. Vieta neatlaisvinama, o matomas failas nustoja augti, kas atrodo kaip sulaužytas sukimas, kol patikrinsite inode. Arba išmokykite procesą vėl atidaryti, arba padarykite, kad sukimas kopijuotų ir kirptų, o ne pervadintų.

Pakartotinio atidarymo kelias yra švaresnis ten, kur programinė įranga jį palaiko: nusiųskite dokumentuotą signalą arba paleiskite dokumentuotą komandą, ir leiskite procesui pačiam atidaryti naują failą. Alternatyva yra copytruncate , kuri nukopijuoja turinį į pasuktą pavadinimą ir tada vietoje apkarpo originalą, todėl aprašas lieka galiojantis, bet įrašai tarp kopijavimo ir apkirpimo prarandami.

systemd paleidžiamų padalinių atveju nukreipkite StandardOutput į žurnalą arba į failą ir leiskite padaliniui valdyti gyvavimo ciklą. Shell ciklas, papildantis per tee -a be jokios dydžio ribos, yra ta tvarka, kuri sutrikimo metu užpildo skaidinį, nes nepavykusi patikra dažnai registruoja daug daugiau nei sveika.

Išbandykite sukimą nelaukdami laikmačio

Derinimo režimas praneša, kas nutiktų, ir nieko neliečia, todėl tai saugus pirmas paleidimas po keitimo. Kai būsite patenkinti, priverskite tikrą sukimą, tada patvirtinkite, kad kita žurnalo eilutė patenka į naują failą, o ne į pervadintą:

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

Skaitykite išvestį ta tvarka. Derinimo ėjimas turėtų įvardyti failą ir numatytus veiksmus; priverstinis paleidimas turėtų sukurti lauktą pasuktą pavadinimą; tail turėtų parodyti naują įrašą po to, kai rašantysis procesas vėl veikia. Auganti df reikšmė ir mažėjantis matomas failas reiškia aukščiau aprašytą aprašo problemą.

Pakartokite priverstinį paleidimą du kartus, kad pamatytumėte, kaip saugojimas elgiasi, kai versijų jau yra. Seniausio failo ištrynimas yra laukiamas rezultatas, o ištrynimo nebuvimas paprastai reiškia, kad skaičius ar pakaitos simbolis pasuktame pavadinime neatitinka to, ką sukūrė logrotate.

Išsaugokite atsukimo galimybę ir rašytinį įrašą

Išsaugokite ankstesnį bloką prieš keitimą ir pasižymėkite, kuris planuotojas jį vykdo, nes atsukimas, kuris atkuria failą, bet ne laikmatį, atkartoja pusę pradinės problemos. Po atkūrimo pasukite kartą rankiniu būdu, tada patvirtinkite, kad rašančiojo proceso paskyra gali rašyti į žurnalo kelią. Jei paslauga veikia pagal systemd, po kiekvieno jos išvesties peradresavimo pakeitimo iš naujo įkelkite padalinį, nes veikiantis procesas toliau rašo į seną tikslą. Perskaitykite keletą kitų žurnalo eilučių patys, užuot pasitikėję, kad padalinys grįžo švariai.

Užrašykite režimą, savininką, saugojimo skaičių ir laukiamą disko biudžetą šalia pačios patikros. Kai vėliau patikra iš vienkartinio scenarijaus taps demonu, sukimo politika turės keistis kartu su ja, ir ta pastaba pasakys kitam žmogui, kuri prielaida sugedo.

Galiausiai laikykite žurnalo sprendimą atskirai nuo atkūrimo sprendimo. Nepavykusi patikra turėtų vadovautis pačios jungties atkūrimo politika, o ne taisykle, paslėpta logrotate viduje, ir jokia registravimo tvarka neturėtų būti priežastis iš naujo paleisti veikiantį tunelį.