Демон, страдающий бессоницей
Давайте начнем с наиболее известного демона crond. В дистрибутив Red Hat 7.3, с которым я экспериментировал при написании данной статьи, входит вариант демона crond, который называется Vixie Cron, по имени его разработчика Пола Викси (Paul Vixie). Но для краткости будем говорить просто "cron".
Системный демон crond предназначен для выполнения регулярно повторяющихся заданий. Обычно crond запускается как системный сервис в процессе начальной загрузки системы и остается активным пока система не выключена. Сразу после старта он просматривает каталоги /var/spool/cron и /etc/cron.d, а также файл /etc/crontab в поисках заданий, которые нужно выполнять. Затем crond просыпается каждую минуту, выполняет предписанные ему задания и снова засыпает до начала следующей минуты.
Чтобы задать cron-у задачу лучше всего воспользоваться командой crontab. Если выполнить ее с опцией -l:
[user]$ crontab -l
то будет выведен текущий список заданий. Если вы еще никаких заданий cron-у не давали, вы увидите в ответ сообщение "no crontab for user". Сформулировать cron-у задачу довольно просто, но, прежде чем пытаться задать ему работу, установите в качестве значения переменной окружения EDITOR указание на любимый (или привычный) текстовый редактор. В противном случае будет вызван редактор vi, с которым я, например, не привык работать. Поэтому я обычно выполняю команду
[user]$ export EDITOR=mcedit
после чего получаю возможность использовать для редактирования списка заданий привычный CoolEdit из пакета Midnight Commander.
После задания значения переменной EDITOR можно выполнить команду
[user]$ crontab -e
по которой будет вызван указанный вами редактор, причем при первом запуске такой команды откроется пустое окно, в котором вы должны сформулировать задание cron-у. Возникает вопрос: а что мешает нам просто запустить любимый редактор, открыть для редактирования нужный файл и внести в него необходимые команды? Этому существует две причины.
Во-первых, файлы, которые хранят задания для cron-а (crontab-файлы), принадлежат root-у и защищены от модификации простыми пользователями. Команда же crontab запускается от имени root-а (для нее установлен так называемый setuid-бит) и имеет доступ к этим файлам. Конечно, если речь идет о вашем персональном компьютере, где вы имеете все права, вам законы не писаны, но лучше все же придерживаться принятых правил игры.
Вторая причина состоит в том, что записи в crontab- файлах должны подчиняться определенным стандартам, быть формализованы, чтобы crond мог их правильно интерпретировать. Команда crontab после того, как вы сохранили вновь отредактированный файл, производит его синтаксический анализ, и, если вы сделали какую-то ошибку, предлагает вам вернуться к его редактированию. Конечно, crontab не может сформулировать за вас задание cron-у, так что правила написания заданий вам необходимо знать. Давайте их рассмотрим.
Каждая строка crontab-файла (кроме строк комментариев, которые обозначаются знаком # в первой позиции) либо устанавливает значение некоторой переменной, либо представляет отдельное задание (ниже приведен пример crontab-файла, можете просмотреть его, чтоб составить первое впечатление).
Строка задания состоит из шести полей, разделяемых пробелами (по крайней мере одним). Первые пять полей отведены для указания времени выполнения задания. В следующей табличке представлены значения, которые можно придавать этим полям
| Поле | Определяет | Числовые значения |
| 1 | Минуты | 0-59 |
| 2 | Часы | 0-23 |
| 3 | Дни месяца | 1-31 |
| 4 | Месяц | 1-12 или три первых буквы английского названия месяца (регистр не имеет значения) |
| 5 | Дни недели | 0-7 или три первых буквы английского названия дня недели (регистр не имеет значения, а числа 0 и 7 оба обозначают воскресенье) |
- список возможных значений, разделенных запятыми (в списках можно использовать только числа, имена не допускаются),
- интервал значений (например, 1-3)
- или звездочку (*), обозначающую любое из допустимых значений для данного поля.
Существует также возможность указать, что данное задание должно выполняться только в каждый n-ый час (минуту, день или месяц), для чего в нужном поле записывают примерно такую комбинацию: "*/n" (кавычки, конечно, нужно опустить, а вместо n поставить конкретное число). Эти варианты записи времени выполнения заданий можно комбинировать, но об этом лучше прочитайте на man-странице crontab(5).
Обратите внимание на то, что для указания дня отведено 2 поля: третье и пятое. Если в обоих полях заданы значения, отличные от *, то задание будет выполняться в те дни, когда хотя бы одно из значений дня совпадает с текущим. Например, если в третьем поле стоит 1,15, а в пятом поле - 5 (или FRI), то задание будет выполняться по первым и пятнадцатым числам каждого месяца, а также каждую пятницу (конечно, если в поле месяцев будет стоять *).
Следующее поле (шестое) содержит подлежащую выполнению командную строку оболочки shell. Считается, что поле команда продолжается до конца строки и может содержать пробелы и символы табуляции. Причем заключать эту командную строку в кавычки не требуется. Как и в обычной командной строке shell, можно указать в этом поле несколько команд, разделенных точкой с запятой (хотя, наверное, лучше написать командный файл и указать в crontab-файле его имя).
Задание переменных окружения для cron рассмотрим на примере переменной MAILTO. Надо сказать, что по умолчанию после выполнения каждой строки crontab-файла cron отсылает рапорт о выполнении задания. Содержанием такого рапорта является вывод исполнявшихся команд. Если не задавать переменную MAILTO, то сообщение отправляется тому пользователю, который задал ему данную задачу. Если вы хотите, чтобы сообщения отправлялись не вам, а, скажем, пользователю с именем fred, то в crontab-файле надо записать строку вида
MAILTO="fred"
Боюсь только, что fred не обрадуется, если его почтовый ящик будет заполняться сообщениями от cron. Если они не нужны и вам, то установите переменную MAILTO в нуль:
MAILTO=""
после чего cron не будет загружать вас лишними письмами. Несколько переменных окружения cron устанавливает автоматически при его запуске.
После завершения редактирования вы, как обычно, сохраняете результаты и выходите из редакторской программы. Если вы сделали ошибки, то увидите такое сообщение:
[user] $ crontab -e crontab: installing new crontab "/tmp/crontab.10348":0: bad day-of-week errors in crontab file, can't install. Do you want to retry the same edit? y
Естественно, придется ответить "y". Если же ошибок не было (или вы их исправили), вы увидите только одну строку:
[user] $ crontab -e crontab: installing new crontab
что означает, что введенные строки заданий сформулированы корректно (но это вовсе не гарантирует, что в поле команд нет ошибок).
В отличие от других процессов-демонов, которые требуют перезапуска после редактирования их конфигурационных файлов, перезапускать процесс crond после того, как пользователь задал новое задание, не требуется. Дело в том, что просыпаясь ежеминутно, cron проверяет время модификации crontab-файлов и перечитывает те файлы заданий, которые изменялись в последнее время. Поэтому не более чем через минуту ваши задания будут "приняты к исполнению".
Пользоваться услугами crond могут все пользователи, зарегистрированные в системе. Правда, суперпользователь может закрыть эту возможность для некоторых пользователей, прописав их имена в специальный файл /etc/cron.deny, либо же разрешив использовать cron только ограниченному числу пользователей, имена которых перечислены в файле /etc/cron.allow. Подробнее об этом вы можете прочитать на man-странице crontab(1), а пока будем считать, что вам такое право предоставлено.
