Iikot ang log ng VPN watchdog nang hindi masisira ang manunulat

Ang isang pagsusuri ng kalusugan ng VPN na nagdadagdag ng isang linya kada minuto ay tahimik na lumilikha ng pangalawang tungkulin: pagpapasya kung paano lumalabas ang mga linyang iyon sa disk. Ang pag-aayos ng tunnel ay walang ginagawa para sa tungkuling iyon, at ang pagpapalit ng pangalan ng file ay hindi nagre-redirect ng prosesong hawak pa rin ang lumang deskriptor. Sagutin muna ang tanong ng destinasyon, pagkatapos itugma ang pag-ikot sa paraan ng pagbukas ng manunulat dito.

Piliin ang destinasyon bago ang patakaran sa pag-ikot

Ang isang yunit ng systemd na nagpapadala na ng output nito sa journal ay nag-iingat ng retention sa isang lugar. Ipinapatupad ng journald ang mga limitasyon tulad ng SystemMaxUse at MaxRetentionSec , kaya ang watchdog na nag-log doon ay nagmamana ng hangganan nang walang karagdagang trabaho. Ang pagdaragdag ng pangalawang file na walang hangganan sa tabi nito ay nagdodoble ng maintenance nang walang pakinabang.

Ang isang nakalaang file ay nakakakuha ng lugar nito kapag may ibang nagbabasa nito: isang parser, isang pag-export ng audit o isang pahinang umaasa sa isang matatag na landas. Kapag nagawa na ang desisyong iyon, kailangan ng file ang may-ari, mode at patakaran sa pag-ikot na nakasulat nang magkasama, dahil ang tatlo ay tama lamang bilang isang set. Ang landas na kahit sino ay makakagawa ay landas din na kahit sino ay makakapalit, kaya ang mga pahintulot ng direktoryo ay kabilang sa parehong tala. Isulat ang lahat ng iyon sa tabi ng pagsusuri at ang susunod na pag-edit ay magsisimula sa parehong mga katotohanan.

Isulat ang bloke upang tumugma sa manunulat

Magsimula sa isang manunulat na nagbubukas ng landas sa bawat tawag, nagdadagdag ng isang linya at lumalabas. Nabubuhay ang pattern na iyon sa pag-ikot nang walang anumang kooperasyon mula sa proseso, dahil binubuksan ng susunod na pagtakbo ang file na kasalukuyang nasa landas na iyon. Ang bloke sa ibaba ay nag-iingat ng isang linggong bersyon at muling gumagawa ng file kasama ang may-ari at mode na kailangan ng manunulat:

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

Ang manwal ng logrotate ay tumutukoy sa bilang bilang bilang ng mga nakaikot na bersyon na itinatago, hindi bilang garantiya ng pitong araw na kasaysayan, at ang keyword na daily ay sinusuri kapag tumatakbo ang trabaho sa halip na kumilos bilang sarili nitong scheduler. Sa karamihan ng mga distribusyon, ang isang timer ng systemd o entry ng cron ay nagmamay-ari na ng tawag na iyon, kaya suriin kung alin ang umiiral bago magdagdag ng pangalawa. Ang pagtutugma ng pagmamay-ari ay mas mahalaga kaysa sa bilang ng retention. Ang pagkopya ng mode para sa root lamang sa isang file na isinulat ng service account ay humihinto sa pag-log sa susunod na pag-ikot, at ang pagkabigo ay lumilitaw pagkalipas ng mga oras bilang isang lipas na timestamp sa halip na bilang isang error. Kumpirmahin ang user ng manunulat bago kopyahin ang isang bloke mula sa ibang lugar.

Ang manunulat na hindi kailanman muling bumubukas ay nangangailangan ng ibang lunas

Ang isang pangmatagalang prosesong may bukas na deskriptor ay patuloy na nagsusulat sa pinangalanang muli na inode. Hindi nabubuksan ang espasyo at humihinto ang paglaki ng nakikitang file, na mukhang sirang pag-ikot hanggang suriin mo ang inode. Alinman sa turuan ang proseso na muling buksan, o gawing kopya at putol ang pag-ikot sa halip na palitan ang pangalan.

Ang landas ng muling pagbukas ay mas malinis kung saan sinusuportahan ito ng software: ipadala ang dokumentadong signal o patakbuhin ang dokumentadong utos, at hayaang buksan ng proseso mismo ang bagong file. Ang alternatibo ay copytruncate , na kumokopya ng nilalaman sa nakaikot na pangalan at pagkatapos ay pumutol sa orihinal sa lugar nito, kaya nananatiling wasto ang deskriptor ngunit nawawala ang mga sulat na nahuhulog sa pagitan ng kopya at pagputol.

Para sa mga yunit na sinisimulan ng systemd, ituro ang StandardOutput sa journal o sa isang file at hayaang ang yunit ang magmay-ari ng lifecycle. Ang isang loop ng shell na nagdadagdag sa pamamagitan ng tee -a nang walang limitasyon sa laki ay ang kaayusang pumupuno sa isang partisyon sa panahon ng pagkawala, dahil ang isang nabigong pagsusuri ay kadalasang nag-log ng higit pa kaysa sa isang malusog.

Subukan ang pag-ikot nang hindi naghihintay sa timer

Ang debug mode ay nag-uulat kung ano ang mangyayari at hindi gumagalaw ng anuman, na ginagawa itong ligtas na unang pagtakbo pagkatapos ng pag-edit. Pilitin ang isang tunay na pag-ikot kapag nasiyahan ka na, pagkatapos ay kumpirmahin na ang susunod na linya ng log ay dumarating sa bagong file sa halip na sa pinangalanang muli:

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

Basahin ang output sa ganoong pagkakasunod-sunod. Ang debug pass ay dapat pangalanan ang file at ang mga pagkilos na nilalayon; ang sapilitang pagtakbo ay dapat gumawa ng inaasahang nakaikot na pangalan; ang tail ay dapat magpakita ng sariwang entry pagkatapos tumakbo muli ang manunulat. Ang lumalaking halaga ng df na may lumiliit na nakikitang file ay nangangahulugan ng problemang deskriptor na inilarawan sa itaas.

Ulitin ang sapilitang pagtakbo nang dalawang beses upang makita kung paano kumikilos ang retention kapag may mga bersyon na. Ang pagtanggal ng pinakamatandang file ay ang inaasahang resulta, at ang nawawalang pagtanggal ay karaniwang nangangahulugan na ang bilang o wildcard sa nakaikot na pangalan ay hindi tumutugma sa ginawa ng logrotate.

Magtago ng rollback at nakasulat na tala

I-save ang naunang bloke bago mag-edit, at tandaan kung aling scheduler ang nagpapatakbo nito, dahil ang pagbabalik na nagbabalik ng file ngunit hindi ang timer ay nagre-reproduce ng kalahati ng orihinal na problema. Iikot nang isang beses gamit ang kamay pagkatapos ng pag-restore, pagkatapos ay kumpirmahin na ang account ng manunulat ay makakasulat sa landas ng log. Kung ang serbisyo ay tumatakbo sa ilalim ng systemd, i-reload ang yunit pagkatapos ng anumang pagbabago sa redirection ng output nito, dahil ang tumatakbong proseso ay patuloy na nagsusulat sa lumang target. Basahin mo mismo ang susunod na mga linya ng log sa halip na umasa na malinis na bumalik ang yunit.

Itala ang mode, may-ari, bilang ng retention at inaasahang badyet sa disk sa tabi ng pagsusuri mismo. Kapag ang pagsusuri ay naging isang daemon mula sa isang beses na script, ang patakaran sa pag-ikot ay kailangang magbago kasama nito, at ang talang iyon ang nagsasabi sa susunod na tao kung aling palagay ang nasira.

Sa huli, panatilihing hiwalay ang desisyon sa log mula sa desisyon sa pagbawi. Ang isang nabigong pagsusuri ay dapat sumunod sa sariling patakaran sa pagbawi ng koneksyon, hindi sa isang tuntuning nakatago sa logrotate, at walang kaayusan ng pag-log ang dapat maging dahilan upang i-restart ang isang gumaganang tunnel.