Полный гайд по systemd timers: Забудьте про Cron в Linux

От /

Почему ваш crontab -e — это прошлое

Десятилетиями cron был стандартом де-факто для планирования задач в Linux. Он прост, надежен и… это всё. В современной, сложной инфраструктуре подход cron — это «слепой» запуск.

Если задача в cron не выполнилась, вы узнаете об этом, когда что-то «упадет». Логирование? Только через syslog или MAILTO. Зависимости? Нельзя сказать cron: «Эй, запусти этот скрипт бэкапа, только после того, как поднимется сеть и смонтируется удаленный диск». Управление ресурсами? Забудьте.

«Админ» использует cron, потому что «так всегда делали». «Архитектор» использует systemd, потому что ему нужен контроль, логирование и управление зависимостями.

systemd — это не просто система инициализации (замена init.d). Это фреймворк для управления всей операционной системой. И его timers (таймеры) — это прямой, нативный и на порядок более мощный преемник cron.

Этот гайд покажет вам на практике, как перенести ваши cron-задачи на systemd timers и почему вы больше никогда не захотите возвращаться назад.

Анатомия современного планировщика

Ключевое отличие: cron — это монолит. Вы пишете в crontab когда и что делать.

systemd разделяет эти понятия на два разных файла (юнита):

  1. .service (Юнит службы): Описывает ЧТО делать. (Например, запустить скрипт).
  2. .timer (Юнит таймера): Описывает КОГДА это делать. (Например, каждый день в 3:00).

Эта связка дает нам невероятную гибкость.

Шаг 1. Практика: Готовим задачу (Юнит .service)

Давайте представим, что у нас есть простой скрипт для очистки кэша или временных файлов.

Создадим сам скрипт:

Bash

# Создаем директорию для наших "архитекторских" скриптов
sudo mkdir -p /opt/admin-future/scripts

# Создаем скрипт
sudo nano /opt/admin-future/scripts/cleanup.sh

Содержимое скрипта (cleanup.sh):

Bash

#!/bin/bash
# Простой скрипт очистки
# Мы используем 'logger' для отправки сообщений в systemd-journal
# Это намного чище, чем 'echo "что-то" >> /var/log/my.log'

logger -t "AdminFutureCleanup" "Начинаю очистку /tmp и /var/tmp..."
find /tmp -type f -mtime +7 -delete
find /var/tmp -type f -mtime +7 -delete
logger -t "AdminFutureCleanup" "Очистка завершена."

Сделаем его исполняемым:

Bash

sudo chmod +x /opt/admin-future/scripts/cleanup.sh

Теперь «обернем» этот скрипт в systemd.service. Это инструкция для системы, как его запускать.

Создаем файл юнита:

Bash

# 'system' означает, что это системный, а не пользовательский юнит
sudo nano /etc/systemd/system/cleanup.service

Содержимое файла (cleanup.service):

Ini, TOML

#
# /etc/systemd/system/cleanup.service
# Описывает "ЧТО" мы делаем.
#

[Unit]
# Человекочитаемое описание. Будет видно в 'systemctl status'
Description=Еженедельная очистка временных директорий
# Это важно! Мы говорим, что наш сервис не должен запускаться,
# пока система не загрузится в многопользовательский режим и
# не будет доступна сеть (хотя для этого скрипта сеть не нужна,
# это хорошая практика для бэкапов).
After=network.target

[Service]
# Type=oneshot означает, что это "одноразовая" задача,
# а не долговременный демон (как, например, nginx).
Type=oneshot

# Указываем полный путь к нашему скрипту
ExecStart=/opt/admin-future/scripts/cleanup.sh

# --- УРОВЕНЬ "АРХИТЕКТОРА" (Безопасность) ---
# Запускаем скрипт от имени непривилегированного пользователя.
# (Не забудьте создать его: useradd -r -s /bin/false cleanup_user)
# User=cleanup_user
# Group=cleanup_user

# Запрещаем скрипту писать в /etc, /usr и т.д.
ProtectSystem=strict
# Даем скрипту свою личную, изолированную /tmp
PrivateTmp=true

[Install]
# Эта секция не используется для таймеров, но полезна
# для сервисов, которые должны стартовать при загрузке.
WantedBy=multi-user.target

Мы только что создали сервис. Мы можем запустить его вручную, чтобы проверить: sudo systemctl start cleanup.service

И (вот оно!) посмотреть логи: sudo journalctl -u cleanup.service

Вы увидите чистый вывод, включая наши сообщения из logger! Уже лучше, чем cron.

Шаг 2. Создаем расписание (Юнит .timer)

Наш .service готов. Теперь скажем системе, когда его запускать. Для этого мы создадим одноименный .timer файл.

Создаем файл таймера:

Bash

sudo nano /etc/systemd/system/cleanup.timer

Содержимое файла (cleanup.timer):

Ini, TOML

#
# /etc/systemd/system/cleanup.timer
# Описывает "КОГДА" мы запускаем cleanup.service
#

[Unit]
Description=Запускать еженедельную очистку
# Говорим, что этот таймер должен запускать одноименный сервис
# (cleanup.service)
Unit=cleanup.service

[Timer]
# Самая важная часть.
# 'OnCalendar' - это замена синтаксиса cron.
# Формат: DayOfWeek Year-Month-Day Hour:Minute:Second
#
# 'weekly' - это псевдоним (как @weekly в cron)
# Он запустится в 00:00 в понедельник.
OnCalendar=weekly

# А вот так выглядит аналог '0 2 * * *' (каждый день в 2 ночи)
# OnCalendar=*-*-* 02:00:00

# --- УРОВЕНЬ "АРХИТЕКТОРА" (Надежность) ---
# Если сервер был выключен во время планового запуска
# (например, в 2 часа ночи), эта опция говорит systemd
# запустить пропущенную задачу сразу после загрузки.
# Cron так не умеет.
Persistent=true

[Install]
# Мы "привязываем" наш таймер к системной цели 'timers.target'
# Это аналог 'chkconfig on' или 'update-rc.d' для таймеров
WantedBy=timers.target

Шаг 3. Активация и Управление

Мы создали два файла. Теперь «активируем» их.

  1. Перечитываем конфигурацию systemd, чтобы он «увидел» наши новые файлы:Bashsudo systemctl daemon-reload
  2. Запускаем и «включаем» ТАЙМЕР. Важно: Мы запускаем и включаем *.timer файл, а не *.service! Таймер сам запустит сервис по расписанию.Bash# Запускаем таймер (чтобы он начал "тикать") sudo systemctl start cleanup.timer # Включаем автозапуск таймера при загрузке системы sudo systemctl enable cleanup.timer
  3. Проверяем наш новый crontab: Вместо crontab -l, мы используем list-timers:Bashsystemctl list-timers Вы увидите что-то вроде этого:NEXT LEFT LAST PASSED UNIT ACTIVATES Mon 2025-11-03 00:00:00 CET 5 days left n/a n/a cleanup.timer cleanup.service Этот вывод на 1000% информативнее cron. Вы видите:
    • NEXT: Когда следующий запуск.
    • LEFT: Сколько времени осталось.
    • LAST: Когда был последний запуск.
    • PASSED: Сколько времени прошло с последнего запуска.
    • UNIT: Имя нашего таймера.
    • ACTIVATES: Какой .service он активирует.

Вывод: Вы теперь «Архитектор», а не «Cron-Админ»

Давайте подытожим, что мы получили, потратив 5 лишних минут на создание двух файлов:

  1. Централизованное управление: Все задачи видны в systemctl list-timers.
  2. Штатное логирование: journalctl -u cleanup.service показывает полные, ротируемые логи запуска с точным временем и статусом завершения (успех/ошибка).
  3. Управление зависимостями: Мы можем гарантировать, что скрипт бэкапа не запустится, пока не поднимется сеть (After=network-online.target) или не смонтируется диск (Requires=mnt-backup.mount).
  4. Надежность: Опция Persistent=true запускает пропущенные задачи.
  5. Безопасность: Мы можем изолировать задачу, ограничить ее права (ProtectSystem=) и запустить от отдельного пользователя (User=), превратив ее в «песочницу».

Вы не просто автоматизировали задачу. Вы интегрировали ее в операционную систему. Вы построили надежный, наблюдаемый и безопасный процесс. Это и есть мышление «архитектора будущего».

Теги: #linux #systemd #automation #cron #sysadmin #tutorial #devops #bash

🚀 Хотите стать архитектором будущего, а не просто админом? Эта статья — лишь верхушка айсберга. В нашем Telegram-канале «Admin Future» мы каждый день публикуем системные гайды, готовые скрипты, AI-лайфхаки и чеклисты, которые не найти в Google. Мы не просто постим команды — мы строим библиотеку знаний для тех, кто хочет расти от админа до архитектора. Подписывайтесь и становитесь экспертом: Admin Future

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх