30  5      1      *      *      root   periodic monthly

Утилита periodic исполняет все сценарии, расположенные в папке, соответствующей параметру, переданному ей при вызове. Эта папка ищется в каталоге /etc/periodic. Например, запуск periodic daily приведет к выполнению всех скриптов, расположенных в /etc/periodic/daily. Также существует возможность создавать свои периоды обслуживания, для чего должна быть создана новая директория в /etc/periodic, в которую помещаются необходимые скрипты, и добавлена соответствующая строка запуска в crontab. Настроить обслуживание системы под собственные нужды можно в файле /etc/periodic.conf (по умолчанию отсутствует). Настройки по умолчанию заданы в /etc/defaults/periodic.conf. Как видно, эти сценарии выполняют очистку временных файлов, резервное копирование жизненно важной информации, формируют отчеты о состоянии системы и т. д. Основная работа приходится на ежедневное обслуживание (daily). Можно заметить, что в папке /etc/periodic присутствует поддиректория security, хотя в crontab вызова для нее нет. Если поискать внимательно, то команду вызова «periodic security» можно найти в файле /etc/periodic/daily/450.status.security, то есть сбор сведений о состоянии безопасности выполняется в ходе ежедневного обслуживания, но для удобства вынесен в отдельную поддиректорию, и по этой же причине отчет высылается отдельным письмом.

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

В директориях daily, weekly и monthly можно заметить сценарии 999.local. Они позволяют запускать так называемые локальные periodic-сценарии, которые перечисляются в файлах /etc/daily.local, /etc/weekly.local и /etc/monthly.local соответственно. Использование локальных сценариев для собственных нужд более предпочтительно, чем добавление скриптов в /etc/periodic, поскольку позволяет четко разделить системные и пользовательские сценарии и тем самым упростить сопровождение и обновление системы.

Как и для остальных команд, выполняемых по cron, весь стандартный вывод будет перенаправлен на электронный адрес пользователя – владельца таблицы crontab или указанного в переменной MAILTO.

Придумывать полезные примеры для cron труда не составляет. Приведу два первых, пришедших в голову. Предположим, нам нужно контролировать состояние сети. Для этого достаточно занести в ваш пользовательский файл расписаний (системный файл лучше использовать исключительно по системному назначению) строку:

0   *      *      *      *   /sbin/ping –с10 my.provider.ru | /usr/bin/grep ‘avg’ >> /var/log/ping.log

Как это будет работать? В начале каждого часа будет выполняться команда ping, посылающая десять пакетов на адрес вашего провайдера. Из возвращаемой информации будет выбрана последняя строка с результатами, которая будет записана в файл ping.log для последующего анализа таких величин, как среднее время передачи пакета, величина девиации и т. д. Причем в файл будут заноситься только результаты успешного пинга, а все ошибки (типа «Host is down») будут отправляться по электронной почте владельцу файла расписаний.

Следующая строка позволит вам автоматически корректировать ваши (точнее, системные) часы с использованием сервера точного времени:

12  4      *      *      *      /usr/sbin/ntpdate ntp.alaska.edu