Дейв Тейлор - Сценарии командной оболочки. Linux, OS X и Unix. 2-е издание

Листинг 6.9.Запуск сценария verifycron после экспортирования текущего файла cron

$ crontab −l > my.crontab

$ verifycron my.crontab

$ rm my.crontab

Для примера файла crontab, содержащего две ошибки и много комментариев, сценарий вывел результаты, показанные в листинге 6.10.

Листинг 6.10.Результаты проверки файла cron с ошибочными записями с помощью сценария verifycron

$ verifycron sample.crontab

Line 10: Invalid day of week value "Mou"

>>>> 10: 06 22 * * Mou /home/ACeSystem/bin/del_old_ACinventories.pl

Line 12: Invalid minute value "99"

>>>> 12: 99 22 * * 1–3,6 /home/ACeSystem/bin/dump_cust_part_no.pl

Done. Found 2 errors in 13 crontab entries.

Пример файла сценария с двумя ошибками, а также все сценарии, описываемые в этой книге, доступны для загрузки по адресу: http://www.nostarch.com/wcss2/.

В этот сценарий стоило бы добавить несколько усовершенствований. Для начала — проверку допустимости комбинации число/месяц, чтобы пользователи не могли запланировать выполнение задания cron, например, на 31 февраля. Также было бы полезно проверить присутствие запланированной команды в системе, но для этого необходимо выполнить парсинг окончаний записей и обработать переменную PATH (то есть список каталогов, где происходит поиск команд, указанных в сценарии), которая может явно определяться внутри файла crontab. Это довольно непросто… Наконец, попробуйте добавить поддержку таких значений, как @hourly или @reboot, имеющих специальное назначение в cron и применяемых для обозначения времени вызова сценария.

До недавнего времени системы Linux предназначались для работы на серверах, действующих 24 часа в сутки, 7 дней в неделю, постоянно. Это отразилось на реализации планировщика cron: бессмысленно планировать выполнение задание на 2:17 ночи в каждый вторник, если система выключается каждый вечер в 18:00.

Однако многие современные системы Unix и Linux работают на настольных компьютерах и ноутбуках обычных пользователей, которые выключают их в конце дня. Далеко не все пользователи OS X, например, оставляют свои компьютеры включенными на ночь, на выходные или на праздники.

Не произойдет ничего страшного, если пользовательские задания в crontab не выполнятся из-за того, что система была выключена, потому что их можно скорректировать так, чтоб они начали выполняться после включения. Проблема возникает, когда в установленное время не выполняются ежедневные, еженедельные и ежемесячные системные задания.

Назначение сценария в листинге 6.11 состоит в том, чтобы дать администратору возможность выполнить ежедневные, еженедельные и ежемесячные задания непосредственно из командной строки.

Листинг 6.11.Сценарий docron

··#!/bin/bash

··# docron — запускает те ежедневные, еженедельные и ежемесячные системные

··#·· задания cron, которые, скорее всего, не могли быть выполнены из-за

··#·· выключения системы в часы, на которые эти задания

··#·· запланированы.

··rootcron="/etc/crontab" # Этот путь может значительно отличаться в разных

··························#·· версиях Unix и Linux.

··if [$# −ne 1]; then

····echo "Usage: $0 [daily|weekly|monthly]" >&2

····exit 1

··fi

··# Если сценарий запущен не администратором, завершить с сообщением.

··#·· В предыдущих сценариях вы могли видеть, как проверяются USER и LOGNAME,

··#·· но в этой ситуации проверяется непосредственно числовой идентификатор

··#·· пользователя. root = 0.

··if ["$(id −u)" −ne 0]; then

····# Здесь также можно использовать $(whoami)!= "root".

····echo "$0: Command must be run as 'root'" >&2

····exit 1

··fi

··# Предполагается, что в системном файле cron имеются записи с метками

··#·· 'daily', 'weekly' и 'monthly' (ежедневно, еженедельно и ежемесячно).

··#·· Если заданий с такими метками нет, это ошибка. Но в случае, если

··#·· такие задания имеются (что соответствует нашим ожиданиям), попытаемся

··#·· сначала получить команду.

··job="$(awk "NF > 6 && /$1/ { for (i=7;i<=NF;i++) print \$i }" $rootcron)"

··if [-z "$job"]; then··# Нет задания? Странно. Ладно, это ошибка.

····echo "$0: Error: no $1 job found in $rootcron" >&2

····exit 1

··fi

··SHELL=$(which sh) # Для соответствия с умолчаниями в cron

··eval $job········# Сценарий завершится вместе с заданием.

Задания cron, находящиеся в каталогах /etc/daily, /etc/weekly и /etc/monthly (или /etc/cron.daily, /etc/cron.weekly и /etc/cron.monthly ), настраиваются совершенно иначе, чем пользовательские файлы crontab: это каталоги с комплектами сценариев, по одному на задание, которые выполняются механизмом crontab, как определено в файле /etc/crontab . Еще бо́льшую путаницу вносит использование другого формата для определения записей в файле /etc/crontab — он добавляет дополнительное поле, определяющее действующий идентификатор пользователя для задания.

Запись в файле /etc/crontab определяет час (во втором поле в выводе, показанном ниже), в который следует запускать ежедневные, еженедельные и ежемесячные задания, в формате, совершенно отличающемся от того, который видят обычные пользователи Linux:

$ egrep '(daily|weekly|monthly)' /etc/crontab

# Запустить ежедневные/еженедельные/ежемесячные задания.

15······3······ *······ *······ *······ root·· periodic daily

30······4······ *······ *······ 6······ root·· periodic weekly

30······5······ 1······ *······ *······ root·· periodic monthly

Что случится с ежедневными, еженедельными и ежемесячными заданиями, если система будет выключена в 3:15 каждую ночь, в 4:30 по субботам и в 5:30 первого числа каждого месяца? Ничего. Они просто не выполнятся.

Вместо того, чтобы пытаться заставить cron выполнить задания, сценарий, написанный нами, идентифицирует их в файле и выполняет их непосредственно с помощью команды eval в самой последней строке . Единственное отличие от запуска заданий из сценария состоит в том, что вывод заданий, запускаемых из cron, автоматически преобразуется в электронное письмо, тогда как этот сценарий отображает весь вывод на экране.

Впрочем, воспроизвести поведение cron и отправить вывод по электронной почте можно и с помощью сценария, показанного ниже:

./docron weekly | mail −E — s "weekly cron job" admin

Этот сценарий должен запускаться с привилегиями root и одним параметром −daily, weekly или monthly, — указывающим, какую группу системных заданий cron выполнить. Как обычно, для запуска любого сценария с привилегиями root мы настоятельно рекомендуем использовать команду sudo.