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

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.

Результаты

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

Усовершенствование сценария

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

Как одно из решений можно создать три пустых файла, по одному для ежедневных, еженедельных и ежемесячных заданий, и затем добавить новые записи в каталоги /etc/daily, /etc/weekly и /etc/monthly, обновляющие время последней модификации соответствующего файла командой touch. Это решило бы половину проблемы: сценарий docron мог бы проверять, когда повторяющееся задание cron выполнялось последний раз, и сразу прекращать выполнение, если прошло недостаточно времени.

Но это решение не обрабатывает, например, такую ситуацию: через шесть недель после последнего запуска ежемесячных заданий cron администратор запустил сценарий docron, чтобы выполнить ежемесячные задания. Затем, через четыре дня кто-то из сотрудников позабыл выключить свой компьютер и cron выполнил ежемесячные задания. Как cron узнает, что не должен их выполнять?

В соответствующий каталог можно добавить два сценария. Один должен запускаться первым из run-script или periodic (стандартные инструменты запуска заданий cron) и снимать бит права на выполнение со всех сценариев в каталоге, кроме парного ему сценария, который должен снова устанавливать бит права на выполнение после того, как run-script или periodic просканирует каталог и установит, что ничего не должен выполнять: в каталоге нет выполняемых файлов и поэтому cron не запустит их. Однако это не идеальное решение, потому что не гарантирует определенный порядок запуска, а если мы не сможем гарантировать порядок, в котором будут запускаться новые сценарии, все решение становится непригодным.

В действительности эта дилемма не имеет надежного решения. Если только речь не идет о создании обертки для run-script или periodic, которая будет знать, как управлять запоминанием времени, чтобы гарантировать невозможность слишком частого запуска заданий. Впрочем, не исключено, что мы вообще зря беспокоимся об этом.

№ 50. Ротация файлов журналов

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

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

mv $log.2 $log.3

mv $log.1 $log.2

mv $log $log.1

touch $log

Если запускать эту группу команд раз в неделю, в вашем распоряжении всегда будет месячный архив информации из файла журнала, разделенный на порции недельного объема. Однако легко можно создать сценарий, который проделает ту же операцию сразу со всеми файлами журналов в каталоге /var/log, освободив тем самым сценарии анализа от лишнего бремени и организовав ротацию файлов даже в течение месяцев, когда администратор ничего не анализировал.