Comments 66
Ну, открытием он для меня был очень давно, но инструмент, безусловно полезный и простой до банальности. Я там уже писал, что очень люблю программы в этой традиции.
И вот в первый-же день (скорее даже час) работы я «промахнулся» и узнал, что в Centos у crontab нет «глупых» вопросов а-ля
# crontab -r
remove crontab for root?
Всю ночь я его восстанавливал по логам. Странно, что не уволили…
Ограничение, что крон может запускать задачи не чаще чем раз в секунду заставляло писать свои костыли.
Крайне не хватало возможности указать частоту опроса, пускай и с перезапуском самого крона.
Больше похоже на компромис, который сложился исторически, когда машины были ещё не так быстры. Частота в секунду для современных компьютеров была бы приемлемой, наверно.
Смею предположить, что, во-первых, ежесекундные задачи — дело редкое, а во-вторых, в свое время ежесекундный запуск чего-либо было непозволительной роскошью.
man systemd.timers
Надо бы указать версию вашего дистрибутива и крона. Но вообще использование скриптов-оберток — стандартный подход.
Логов, кстати, у кронов может и не быть, стандартно бывает только отправка на почту, указанную в переменной MAILTO.
Если хочется разобраться подробней, то можно попровать вызывать прямиком шелл с вашей командой, так, как его вызывает сам cron: /bin/sh -c "cp /from/file /to/file". Часто путаница бывает связана с тем, что шелл по умолчанию берется POSIX-совместимый и запущенный в неинтерактивном режиме.
Однажды ковырялся в консоли и тут появляется сообщение: у вас есть новый емейл, по такому пути можете найти. «Ничего себе, консоль мне пишет про емейлы» — подумал я и, действительно, нашёл сообщение от крона в емейлах. Очень удобно оказалось.
Скрипт удобен тем, что его можно как вручную для теста запустить, так и кроном выполнить.
И в случае crontab -r скрипт останется.
точно, надо ж экранировать проценты, т.к. проценты в кроне означают перенос строки, для передачи в команды нескольких строк :-)
Из стандарта:
A <percent-sign> character in this field shall be translated to a <newline>. Any character preceded by a
<backslash> (including the '%' ) shall cause that character to be treated literally. Only the first line (up to a
'%' or end-of-line) of the command field shall be executed by the command interpreter. The other lines shall > be made available to the command as standard input.
вам ниже ответили, что проценты надо экранировать :-) Там же я привел выжимку из стандарта
У logrotate'а есть параметр olddir и описание задачи выглядит так, как будто стоило использовать его для копирования, а сам logrotate запускать cron'ом
Формат crontab такой же + дополнения.
Я использую версию 1.17.119.0 от 2005 года, которая, как заявлено, работает на Win95 — WinXP, но у меня работает и на Win7 и кажется даже на Win10.
Неоднократно пробовал пользоваться родным виндовым планировщиком, но потом опять уходил на nnCron Lite.
Так-то крутая была софтина, но она написана на форте и скрипты под нее надо было писать на диалекте форта, а это чудовищно. Обратная польская запись хороша для машин, а не для людей.
Для тех, кто ещё не столкнулся с этой замечательной фичей, процитирую википедию:
Все условия (времени запуска) проверяются по «логическому И», кроме условий «день недели» и «день месяца» — указанные совместно, они обрабатываются по «логическому ИЛИ», то есть «по любому из дней», что отражено в документации (Ubuntu, Debian, FreeBSD). Однако такая логика неочевидна и не позволяет создать условие типа «первый понедельник каждого месяца» или «каждую пятницу в 13 число».
Приходится писать костыли в баше.
Секунды (тем более — миллисекунды) традиционно не делали, т.к. для всех пользователей каждую секунду проверять задачи — дело неблагодарное. Тут Крон не поможет.
Еще более гранулярно, на миллисекундах, фактически не имеет смысла делать, т.к. вся эта возня с шеллами, форками и экзеками уже занимает сотни миллисекунд, точности не выйдет.
В таких случаях вам понадобится что-то очень специальное.
Тогда для себя я решил, насчет секунд, что раз cron имеет точность в минуту, значит так и надо и этот гвоздь торчит из стула не просто так. Поэтому ИМХО, если нужна точность лучше, чем минуты, нужно делать это в своей программе, а из крона только проверять, не упала ли эта программа и перезапускать в случае падения.
1) включаются вместе с ОС и имеют возможность запуска скрипта после запуска зависимостей (т.е., когда включилась база данных или обработчик очередей)
2) функция контроля (перезагружать ли после ошибки или штатного завершения работы, сколько попыток сделать, с каким диапазоном сделать перезапуск)
3) все это логгируется и вытаскивается через тот же journalctl
А сам скрипт исполняет работу и спит от 5 до 30 секунд. Чтобы не текла память, можно также завершать скрипт после получаса-часа работы, тогда systemctl автоматически включит задачу повторно.
Поэтому cron в этом смысле выглядит довольно странным и не универсальным решением.
«Каждая программа в своем развитии доходит до необходимости отправлять электронную почту» © Не помню кто.
В смысле каждая программа тащит в себя все фичи, до которых только может дотянуться.
Крон не странная программа, это очень простая штука, для 95% задач его хватает и в этом его сила. В простоте.
Универсальные решения это не UNIX way.
Но для наблюдателя над ходом исполнения программы — возможно, это не самое эффективное решение, хотя и довольно простое. Конечно, все зависит от программы, которая запускается кроном, но supervisord или systemctl в этом плане более заточенные.
Если нужно запустить программу в нужную миллисекунду, то тут уже нехило пахнет специальной операционной системой реального времени да еще и с очерь хорошей синхронизацией времени.
Шаги и интервалы можно смешивать:
# Запускается каждую вторую минуту первых десяти минут каждого часа 0-10/2 * * * * /path/to/exec
Я бы не использовал в описании интервально-шаговых событий слово «каждую». Отнюдь, не придираюсь, просто зачастую формулировку «каждую вторую» воспринимают как «каждую чётную».
С учётом данного примера с 0-й левой границей интервала это справедливо, но может вызывать непонимание конструкций вида
1-11/2 * * * * /path/to/execРазумеется и здесь можно говорить «каждую вторую начиная с 1», но сам стараюсь использовать формулировки «через две минуты», «с шагом в две минуты».
Что раздражает у crontab, так это отсутствие (?) подтверждения при удалении через crontab -r. Особенно с учётом того, что клавиши "e" и "r" расположены рядом на клавиатуре, поэтому набирая "crontab -e" нужно быть КРАЙНЕ внимательным.
Думаю, не лишним было бы пояснение про пользователей указываемых в /etc/crontab в шестом столбце. У меня cronie ругается на него и говорит, что нет такой команды. Про это почему-то нигде нет информации.
Cron в Linux: история, использование и устройство