Что такое таймеры в systemd и как их использовать для планирования задач?

А, слушай, про таймеры в systemd! Это же, блядь, такая штука, которая cron на бобах обыгрывает, ёпта. Представь себе: cron — это как старый дедок с костылями, который по расписанию бубнит одно и то же, а systemd timer — это уже современный робот-уборщик, который не только пылесосит, но и логи пишет красиво, и если ты проспал — он тебе напомнит. Ебать мои старые костыли, какая разница!

Чем они, сука, круче старого крона:

• В системе как дома: Всё через systemctl крутишь, логи в journalctl — красота, а не жизнь. Никаких писюлек с crontab -e, где запятую не там поставил — и всё, пизда рулю, задача не работает, а ты и не знаешь почему.
• Умные зависимости: Можешь заставить задачу стартануть только после того, как нужный диск примонтируется. У крона с этим, конечно, пиздец — он тупо попробует и сольёт в ошибку, если диск не готов.
• Гибкое расписание: Тут тебе и "каждый будний день", и "раз в неделю", и "через 15 минут после загрузки". Cron, конечно, тоже не дурак, но тут как-то... элегантнее, что ли.
• Persistent mode — просто песня: Если комп в 2 ночи был выключен, а задача должна была в это время запуститься, то при следующем включении она всё равно выполнится. У крона, понятное дело, доверия ебать ноль — пропустил время, и хуй с горы, считай, день потерян.

Пример: Делаем ежедневный бэкап, чтобы не охуеть потом

1. Сервис (/etc/systemd/system/backup.service): Тут мы описываем, что делать. Типа, сам скрипт.

   [Unit]
   Description=Database backup job
   
   [Service]
   Type=oneshot
   ExecStart=/usr/local/bin/backup-script.sh
   User=backup-user

   Всё просто: запусти разовый скрипт от имени специального юзера. oneshot — значит, запустился, отработал, завершился. Никаких демонов.

2. Таймер (/etc/systemd/system/backup.timer): А вот это — когда делать. Самое интересное.

   [Unit]
   Description=Run backup daily at 2 AM
   
   [Timer]
   OnCalendar=*-*-* 02:00:00  # Каждый день в 2 ночи. Можно и "Mon..Fri", если только по будням.
   Persistent=true             # Вот эта волшебная фигня! Если проспал — выполнится позже.
   
   [Install]
   WantedBy=timers.target

3. Запускаем эту банду:

   # Разрешаем таймеру стартовать при загрузке
   sudo systemctl enable backup.timer
   # Запускаем его прямо сейчас (он сам будет спать до 2 ночи)
   sudo systemctl start backup.timer
   # Смотрим, жив ли он и когда следующий пиздёж
   systemctl status backup.timer  # Там будет строчка "Trigger: ..." — следующее срабатывание.
   # А если что-то пошло не так, смотрим логи самого скрипта
   journalctl -u backup.service

Где это в DevOps впаривают? Да везде! Очистка старых логов, чтобы места не жрали овердохуища, синхронизация конфигов между серваками, какие-нибудь периодические проверки здоровья сервисов. В общем, вещь, блядь, must have, а не "надо бы попробовать". Хуй с винтом, что cron проще — тут надёжнее и контролировать удобнее.