Дайте невеликому запланованому завданню чіткі межі.

Визначте одну скінченну одиницю роботи

Уявіть персональний інструмент, який перебудовує невеликий щоденний підсумок з наявних записів. Завдання читає обмежений набір даних, готує один замінювальний підсумок і завершується. Це не веб-сервер і він не повинен продовжувати працювати між запланованими запусками. Запишіть вхідні дані, призначення, очікувану тривалість і те, що вважається успіхом, перед додаванням таймера.

Приклад припускає хост Linux із systemd та util-linux flock, доступ адміністратора та наявний непривілейований обліковий запис і групу з іменем fieldjob. Його перевірений скрипт завдання розташований за /opt/field-jobs/build-summary і працює на передньому плані. Адміністратор володіє цим скриптом; обліковий запис завдання може читати та виконувати його, але не може переписувати його код. Перевірте шляхи виконуваних файлів у вашому дистрибутиві. Це шаблони, а не встановлений сервіс планування OffVPS.

Скрипт повинен повідомляти про збій з ненульовим статусом виходу. Для замінювальних файлів проєктуйте його так, щоб підготувати та перевірити тимчасовий результат перед публікацією. Для роботи з базою даних використовуйте механізм транзакцій або дедуплікації бази даних. Саме лише блокування не може зробити частково виконане завдання безпечним для повторення.

Виберіть часовий пояс і політику пропущених запусків

Наш підсумок корисний раз на день о 02:15 UTC. Використовуйте явний часовий пояс, щоб локальний часовий пояс машини не був невидимою залежністю. UTC уникає сезонних змін годинника в цьому прикладі; бізнес-завдання, прив'язане до місцевого цивільного часу, потребує названого часового поясу та перегляду його поведінки щодо літнього часу. довідка про час systemd описує календарні вирази.

Збережіть цей шаблон як /etc/systemd/system/field-summary.timer на призначеному VPS після перевірки імен:

[Unit]
Description=Daily personal-tool summary

[Timer]
OnCalendar=*-*-* 02:15:00 UTC
Persistent=true
Unit=field-summary.service

[Install]
WantedBy=timers.target

Persistent=true запитує активацію наздоганяння після неактивного періоду, якщо календарну подію було пропущено. Він не відтворює окремий запуск для кожного пропущеного дня. Таймер також не запускає інший екземпляр тієї самої служби, поки ця служба активна. Ці поведінки та точність планування висвітлені в довідці про таймер. Вирішіть, чи корисний пізній підсумок, перш ніж увімкнути наздоганяння.

Встановіть службового користувача, каталог стану та блокування

Відповідний /etc/systemd/system/field-summary.service описує роботу:

[Unit]
Description=Build the personal-tool summary

[Service]
Type=oneshot
User=fieldjob
Group=fieldjob
WorkingDirectory=/opt/field-jobs
StateDirectory=field-summary
StateDirectoryMode=0700
UMask=0077
ExecStart=/usr/bin/flock --nonblock --conflict-exit-code 75 /var/lib/field-summary/job.lock /opt/field-jobs/build-summary
TimeoutStartSec=5min
StandardOutput=journal
StandardError=journal

Type=oneshot підходить для команди, що завершується; явний тайм-аут запуску обмежує цей приклад. Не додавайте RemainAfterExit=yes до служби, яка повинна ставати неактивною після кожного запуску. Дивіться семантику служб systemd. Встановіть тайм-аут відповідно до робочого навантаження та зробіть переривання безпечним, а не припускайте, що п'ять хвилин підходять для кожного завдання.

Для цієї системної служби StateDirectory створює названий каталог під /var/lib із власністю служби. Робочий каталог, користувач, дозволи та призначення виводу є явними; скрипт повинен використовувати абсолютні шляхи для власних інструментів і даних. Правила середовища та каталогів задокументовані в довідці про виконання systemd. Не розміщуйте секретні значення в аргументах командного рядка та не журналюйте їх.

Неблокуючий flock обгортка завершується з кодом 75, коли інший кооперативний виклик утримує це блокування. Ми навмисно залишаємо це як видимий збій, що потребує перегляду, а не вважаємо пропущений підсумок виконаною роботою. Усі ручні виклики повинні використовувати ту саму обгортку та шлях блокування. Не видаляйте файл блокування, щоб звільнити запущене завдання: новий файл може створити окреме блокування. Це шаблон локальної файлової системи, а не розподілене блокування між екземплярами VPS. Дивіться посібник upstream flock.

Перевірте файли, потім спробуйте один контрольований запуск

Використовуйте одноразовий набір даних із вимкненою вихідною поштою, платежами та іншими побічними ефектами для першого запуску. Перед активацією перегляньте розібраний розклад і файли модулів на цьому тестовому хості:

systemd-analyze calendar '*-*-* 02:15:00 UTC'
systemd-analyze verify /etc/systemd/system/field-summary.service /etc/systemd/system/field-summary.timer

Ці перевірки можуть виявити помилки в модулях і розкладі; вони не можуть встановити, що ваш скрипт створює правильний підсумок. довідка systemd-analyze пояснює їхній обсяг. Після виправлення помилок завантажте перевірені файли та явно запустіть тестове завдання:

sudo systemctl daemon-reload &&
  sudo systemctl start field-summary.service
systemctl status field-summary.service --no-pager
sudo journalctl -u field-summary.service --since "10 minutes ago" --no-pager

Очікуйте скінченний успішний виклик і перевірений вихідний артефакт; успішний oneshot може згодом показувати неактивний стан. Перевіряйте сам результат, включно з поведінкою на порожньому вході. Зробіть тестовий запуск навмисно повільним, викличте ту саму заблоковану команду двічі на тестовому наборі даних і переконайтеся, що другий виклик повідомляє про конфлікт блокування, не записуючи конкуруючий результат.

Увімкніть розклад лише після перевірки його виводу

sudo systemctl enable --now field-summary.timer
systemctl list-timers field-summary.timer --all

Перевірте наступний запланований час, потім перегляньте перший запланований результат. Зберігайте час початку, час завершення, кількість оброблених елементів і результат у журналах скрипту. Відсутній запис про успіх — це причина для перевірки, а не доказ, що завдання виконувалося. Зверніться до команд timer та activation у systemctl.

Щоб призупинити майбутні запуски, використовуйте sudo systemctl disable --now field-summary.timer. Це не завершує вже запущену службу. Якщо потрібне переривання, спершу встановіть, чи можна безпечно зупинити її поточний запис. У міру зростання роботи перегляньте тривалість, повторні спроби та ліміти зовнішніх API; кілька машин потребують спільної координації. Продовжте з сценарієм персональних інструментів та вправою відновлення для даних, які підтримує ця автоматизація.