Следващо поколение Cron със systemd Създаване на таймер

Трябва ли да планирате някаква задача в бъдеще на вашия компютър? Това може да изглежда просто - в края на краищата вашата миялна машина може да изчака преди стартирането с помощта на бутон - но понякога компютрите изпълняват толкова прости задачи толкова трудно.Но ако имате някакъв опит, вероятно сте чували cron, този софтуер, изцяло посветен на стартирането на правилната задача в точното време. Но този инструмент наистина е проектиран с мисъл за простота и в крайна сметка може да имате лоши изненади.Ако някога сте успели да планирате задача в Windows, сте използвали Windows Task Planner. Той има GUI по подразбиране, но не го прави толкова лесен за използване: тези две системи просто стартират процес в определен час и дата.

За да разбера как systemd може да ви бъде от полза там, ще взема пример.

Какви клопки системните таймери ще ви избегнат?

Ако някога притежавате машина с данни, които ви интересуват, ще искате да имате копие на вашите данни на друго, вероятно по-безопасно място. Ако управлявате сървър, това е задължително: в края на краищата, как ще се възстановите, ако твърдият ви диск се провали и ви попречи да възстановите всички данни?

Така че като отговорно лице създавате резервно копие всяка седмица или всеки ден. Можете да го настроите с помощта на cron, планирате го в 4:24 ч., Но тук започва проблемът: какво ще стане, ако сървърът ви е изключен от 4:10 до 4:30 ч. По някаква причина?

Е, вероятно cron просто ще пропусне това архивиране. Това може да е от решаващо значение, ако това се случва често и безшумно или ако вашият код разчита на факта, че се изпълнява и в противен случай може да се провали. Обикновено това се случва, когато настроите задача за почистване чрез cron и тя не се стартира. Изведнъж вашият код може да няма достатъчно място за продължаване и ще се счупи - тъжно е, толкова тъжна ситуация, нали, г-н Елтън Джон.

Ако обаче пропуснатото стартиране може да е проблем, представете си една секунда - леле, Джон Ленън сега? - че вашата задача е твърде бавна. Ако вашата задача е настроена да се изпълнява на всеки 10 минути, но отнема 15 минути за завършване, cron или Windows с радост ще стартира друга задача, дори ако текущата задача все още не е изчезнала - и така, ще имате 2 екземпляра на вашата задача, изпълняващи се едновременно , кой е перфектна рецепта за бедствие. Когато една програма работи едновременно, докато не е предназначена за това, тя наистина ще повреди файлове, други софтуери, бази данни - и вашият сървър изведнъж се превръща в потъващ кораб като Титаник.

Добре, може би отивам твърде далеч с Титаник, но вие разбирате идеята. Въпреки че systemd не би могъл да направи много за спасяването на този кораб, той може да ви помогне с всички тези недостатъци и да ви осигури по-дълга коледна ваканция благодарение на грешките, които ще ви избегне. Време е сега да се запознаете с това как да настроите системни таймери.

Как да планирате автоматизирано архивиране на сървъра?

На първо място, системните таймери задействат системна услуга, така че преди да планирате задачата си, ще трябва първо да я направите услуга. За щастие написах ръководство за създаване на systemd услуга, по този начин тя ще ви запознае с начина на работа на systemd. Трябва да го прочетете, преди да продължите. Освен ако вие точно знайте какво правите, вашият файл на услугата systemd трябва не съдържат всяка настройка WantedBy =. Ако искате да стартирате услугата си в точно определено време, вероятно не искате да я стартирате при зареждане.

Благодарение на системата за обслужване systemd е невъзможно да имате няколко екземпляра на вашата задача, които да се изпълняват по погрешка: ако задачата вече се изпълнява, тя просто ще пропусне това стартиране и ще остави текущата задача да завърши работата.

След като имате насрочена услуга за планиране, създайте файл със същото име на файла като вашата услуга, с изключение на това, че трябва да завършва с .таймер вместо .обслужване. В нашия пример за автоматизирано архивиране услугата ще бъде автоматизирано архивиране.услуга и таймерът ще бъде автоматизирано архивиране.таймер. И двата файла трябва да са в една и съща директория. Както ви казах в статията за услугата systemd, препоръчвам ви да напишете тези файлове на нормално място, като вашата домашна директория и след това да ги копирате в системна папка, след като приключите с редакциите си.

И така, нека ви покажа как изглежда нашият файл с таймер:

[Мерна единица]
Описание = Планирайте архивиране в извън пиковите часове
[Таймер]
OnCalendar = * - * - * 03:00:00
RandomizedDelaySec = 7200
Постоянен = вярно
[Инсталирай]
WantedBy = таймери.мишена

Подобно на системните услуги, има 3 раздела. [Unit] или [Install] работят точно по същия начин, както е обяснено в статията ми за systemd услуги. Моля, обърнете внимание, че WantedBy = е важно тук, защото таймерите могат да бъдат стартирани или спрени, така че ако не кажете на systemd да стартира вашия таймер по време на зареждане, той никога няма да задейства. таймери.target е специална системна цел за таймери.

Сега, раздел [Таймер]. В него ще намерите всички настройки, свързани с това кога таймерът трябва да се задейства. За нашето автоматизирано архивиране казах на systemd да го стартира между 3:00 и 5:00 в часовата зона на сървъра. Точният час е произволен за всеки ден.

OnCalendar = задава таймера, свързан с времето на вашия сървър (стенен часовник), например всяка неделя в 13:00. Ако преди сте използвали cron, трябва да сте наистина запознати с този синтаксис. Въпреки това има някои допълнителни предимства.

Например, ако искате нещо да се случва на час, можете да направите така:

OnCalendar = почасово

и всеки ден:

OnCalendar = всеки ден

Всъщност той поддържа всички от следните стойности:

1. на минута
2. на час
3. ежедневно
4. месечно
5. седмично
6. годишно
7. на тримесечие
8. полу годишно

Има обаче проблем с тези ключови думи: например ежедневните тригери винаги са полунощ, което често е пиков час в изчислителните системи. Ето защо се препоръчва да се използва RandomizedDelaySec = (използването му е посочено по-долу). Така или иначе за архивиране не е добър вариант: полунощ не е извън пиковите часове, а по-скоро обратното. Затова трябва да зададем по-точно, когато искаме да видим, че тази задача е стартирана.

Ако искате повече контрол, можете да напишете дата като 2018-12-06 12:49:37. Е, ако сте толкова конкретни, просто ще задействате таймера веднъж. За да го направите повтарящ се, ще замените някой от тези елементи със * звездичка.

OnCalendar = * - * - * 03:00:00

Както можете да видите по-горе, в нашия пример за архивиране цялата част с датата е * - * - *, което означава, че трябва да се случва всеки ден от всеки месец на всяка година. Сега, ако го направите:

OnCalendar = * - 12-25 03:00:00

След това тя работи на всеки 25 декември в 3 ч. Сутринта. Перфектен системен таймер за Дядо Коледа - дори да се съмнявам, че някога ще му трябва! Така че звездичката добавя повторение там, където го поставите. Ако го поставите в полето година, това означава „всяка година“ и т.н.

И накрая, можете да добавите UTC в края на реда, за да използвате UTC време вместо местна часова зона. Например, някои услуги нулират своите квоти за API в полунощ, но за да избегнат всякакво пристрастие на часовата зона, което използва UTC. Така че за такива задачи бихте направили:

OnCalendar = ежедневно UTC

Сега нека решим друг проблем: пиковите часове. systemd също има настройка за борба срещу това.

RandomizedDelaySec = позволява да се забави задачата за произволен период от време. Стойността е максималният брой секунди, които таймерът ще забави. Той е специално предназначен за такива случаи. Спомняте си, че в systemd всеки ден винаги се задейства в полунощ? Е, седмичното винаги се задейства в понеделник в полунощ, а ежегодно в 1 полунощ на 1 януари, един от най-лошите пикове през годината с прекъсвания в мрежата навсякъде. Със сигурност не искате това да се случи.

Като добавите забавяне, вие премахвате този проблем: той автоматично ще забави вашата задача в неизвестно време. Случайността тук е важна, защото е много по-вероятно да бъде дори когато е произволна и равномерното натоварване позволява по-добра оптимизация на задачите ви.

Кажете, че трябва да изпълнявате задачите си около 7 часа сутринта, но искате да позволите малко забавяне от максимум 15 минути, бихте направили така:

RandomizedDelaySec = 900

Това трябва да е достатъчно за закъснения. Понякога дори милисекунди закъснения са достатъчни, за да се предотвратят нежелани скокове.

Постоянен = се грижи за пропуснати задействания на таймера. Ами ако сървърът ви е изключен през нощта? Е, архивирането никога няма да се задейства. Задаването му на true позволява в такива случаи systemd да го стартира при следващото зареждане. По този начин знаете по един или друг начин, задачата на таймера ще бъде изпълнена. Използването му е просто, просто правите това:

Постоянен = вярно

Това обаче има един недостатък, който така или иначе е наистина трудно да се избегне: когато са пропуснати множество задачи от различни таймери, всички те ще се изпълняват при зареждане и ще забавят това зареждане. Според мен това е много по-добре, отколкото ако никога не се изпълнява и в края на краищата това е нормално, най-подходящият момент за стартиране на таймера е, когато е насрочен, след това вероятно ще е неподходящ.

OnBootSec = е последната опция, която ще ви покажа (но не на последно място). Това е, ако искате да задействате таймер известно време след зареждане, вместо на базата на календара. Например, ако трябва да проверите при стартиране дали сървърът ви е стартиран правилно и работи ли по предназначение, можете да напишете услуга за проверка и да използвате тази настройка на таймера, за да я задействате, след като системата има достатъчно време за зареждане.

Да предположим, че системата се нуждае от 3 минути за стартиране, можете да направите:

OnBootSec = 180

И въпреки името му, можете също да направите:

OnBootSec = 3 минути

Ако прецизирате OnBootSec = и OnCalendar =, той ще стартира услугата, когато се случи някое от тези 2 събития.

Добре, сега е време да запазите файла си, да го копирате в системната папка, ако сте спазили моя съвет по-горе, и да проверите дали таймерът ви работи правилно.

Активирайте новия си таймер и мониторинг

За да тествате новия си таймер, трябва да кажете на systemd, че сте добавили нов таймер, така че трябва да въведете тази команда:

$ sudo systemctl daemon-reload

Сега systemd ще вземе предвид новия ви таймер и ще разгледа внимателно кога да изпълни вашата задача. Тъй като systemd винаги се изпълнява, в края на краищата това е един от най-добрите кандидати за управление и изпълнение на вашите планирани задачи.

Едно нещо обаче може да ви се стори неинтуитивно: таймерът по подразбиране е деактивиран. За да го активирате, трябва да направите тази команда:

$ sudo systemctl enable --now автоматизирано архивиране.таймер

След това вероятно ще искате да видите дали таймерът ви действа според очакванията. Добра новина: systemd е дори достатъчно любезен, за да има команда, която ви казва кога е бил стартиран за последно и кога е насрочено следващото стартиране (освен ако таймерът е настроен да работи само при зареждане, тъй като systemd не знае кога системата ще се зареди отново, очевидно). Ето тази команда:

$ systemctl статус автоматизирано архивиране.таймер

И накрая, когато вече не се нуждаете от таймера, можете да го деактивирате и:

$ sudo systemctl disable --now automated-backup.таймер

Заключение

Използвайки системни таймери, управлението на планираните задачи е на следващо ниво: честно казано, аз лично смятам, че планираните задачи би трябвало да са такива от години.

О, една малка изненада за вас: всички системни таймери се регистрират в добре структурирана система с филтриране, ротация на дневници и други подобни. Затова ви каня да видите как можете да видите дневници за вашите планирани задачи!