Ратацыя журнала 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 у журнал або ў файл і дайце модулю валодаць жыццёвым цыклам. Цыкл shell, які дапісвае праз tee -a без абмежавання памеру, — гэта канструкцыя, якая запоўніць раздзел падчас збою, бо няўдалая праверка часта піша значна больш, чым здаровая.

Праверце ратацыю, не чакаючы таймера

Рэжым адладкі паведамляе, што адбудзецца, і нічога не чапае, што робіць яго бяспечным першым запускам пасля праўкі. Прымусьце сапраўдную ратацыю, калі задаволены, а затым пераканайцеся, што наступны радок журнала трапляе ў новы файл, а не ў перайменаваны:

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, і ніякая арганізацыя журнала не павінна быць прычынай перазапуску працуючага тунеля.