Ротація журналу 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, і жодне впорядкування журналювання не має бути причиною перезапуску робочого тунелю.