Сборка пакетов/Соглашение по стилю RPM-пакетов/Задания Cron
| 8. Задания для планировщика (cron) | ||
|---|---|---|
Содержание
Задания для планировщика (cron)
Обычный способ давать задания cron'у (с помощью /etc/crontab), имеет некоторые ограничения:
- Задания запускаются в строго определенное время. К примеру, задание назначеное на полночь никогда не будет выполнено, если пользователь всегда выключает на ночь компьютер.
- При обновлении пакета, нет простого способы для обновления параметров задания (или восстановления удаленного задания), потому что вся информация хранится в одном файле.
Поэтому разработчики SUSE добавили следующие расширения к пакету cron:
- Запуска заданий cron'а на регулярной основе (каждый час, день, неделю или месяц), даже если компьютер работает всего по несколько часов в день.
- Каждый пакет может хранить свои задания в отдельных файлах.
Их ипользование и описание: см. далее.
Регулярно выполняемые задания
Некоторые пакеты требуют обязательного регулярного обслуживания, к примеру, очиски кеша, или обновления поисковой базы данных. Для этого SUSE Linux предоставляет следующие директории:
-
/etc/cron.hourly -
/etc/cron.daily -
/etc/cron.weekly -
/etc/cron.monthly
Как это определено в файле /etc/crontab, планировщик cron выполняет скрипт /usr/lib/cron/run-crons каждые 15 минут. Он просматривает директории /etc/cron.{hourly,daily,weekly,monthly}, и проверяет какие скрипты в них пора выполнить. Информация о последнем запуске скриптов хранится в файле /var/spool/cron/lastrun. Подобная схема дает уверенность, что скрипты выполняются регулярно, которой нет в случает если используются статичные записи cron'а, выполняемые в фиксированное время. Использование фиксированного времени для запуска скриптов см. ниже.
Любой пакет может установить свои скрипты в любую из этих директорий. Обычно скрипты добавляются в пакет с помощью дополнительного тега Source(SourceN). Они устанавливаются в секции %install и затем перечисляются в секции %files.
Пример взят из пакета man, для повышения наглядности используется сразу два скрипта:
Source2: cron.daily.do_mandb
Source3: cron.daily.clean_catman
[...]
%install
mkdir -p ${RPM_BUILD_ROOT}/etc/cron.daily
install -m 700 %{SOURCE2} ${RPM_BUILD_ROOT}\
/etc/cron.daily/do_mandb
install -m 700 %{SOURCE3} ${RPM_BUILD_ROOT}\
/etc/cron.daily/clean_catman
[...]
%files
[...]
/etc/cron.daily/clean_catman
/etc/cron.daily/do_mandb
Нет каких-нибудь особенных ограничений для скриптов cron'а. Однако, они должны выполнить все надлежащие проверки. Иначе, большое количество сообщений о сбоях может зафлудить почту системного администратора. К примеру, скрипт должен проверять наличие программы, перед тем как пытаться ее выполнить. И он должен возвращать “0”, даже если при выполнении произошел сбой, кроме случаев когда это действительно важно.
Пример из пакета wwwoffle:
#!/bin/sh
#
# purge the wwwoffle cache directory according to
# the parameters defined in /etc/wwwoffle/wwwoffle.conf
#
if [ -x /usr/bin/wwwoffle ] ; then
/sbin/checkproc /usr/sbin/wwwoffled && \
/usr/bin/wwwoffle -purge -c /etc/wwwoffle/wwwoffle.conf
exit 0
else
exit 0
fi
Это пример правильной проверки, действие выполняется только если программа существует и выполняется.
Следующий пример более сложный, взят из пакета man:
#!/bin/sh
#
# clean_catman. This script was split off cron.daily
# Please add your local changes to cron.daily.local
# since this file will be overwritten, when updating your system.
#
# Copyright (c) 1996-2002 SuSE GmbH Nuernberg, Germany.
#
# please send bugfixes or comments to feedback@suse.de.
#
# Authors:
# Burchard Steinbuild, feedback to http://www.suse.de/feedback
# Florian La Roche, feedback to http://www.suse.de/feedback
#
# paranoia settings
#
umask 022
PATH=/sbin:/bin:/usr/sbin:/usr/bin
export PATH
if [ -f /etc/sysconfig/cron ] ; then
. /etc/sysconfig/cron
fi
# Delete too old preformatted man-pages.
if test "$DELETE_OLD_CATMAN" = yes ; then
if test -z "$CATMAN_ATIME" ; then
# Default is 7 days
CATMAN_ATIME=7
fi
test -e /var/cache/man -a -x /usr/bin/safe-rm && \
find /var/cache/man -name '*.gz' -type f \
-atime +$CATMAN_ATIME -print0 | \
xargs --no-run-if-empty --max-lines=200 --null -- \
/usr/bin/safe-rm
fi
exit 0
Скрипт начинается с установки параноидальных настроек, они используются для увеличения защищенности скрипта с точки зрения безопасности.
See also the proper use of /etc/sysconfig. The user need not edit the script himself, but he can configure the system setting at one place.
Задания выполняемые в строго определенное время
Некоторые пакеты требуют произвольного итервала для своих заданий, а не только ежечасно, ежедневно, еженедельно или ежемесячно. И для этого SUSE Linux предоставляет директорию /etc/cron.d.
Эта директория не для скриптов, а для конфигурационных файлов наподобие /etc/crontab. Доп. информация в man crontab(5). Cron обрабатывает файлы в этой директории подобно файлу /etc/crontab.
Преимущество такого способа хранения задания, в том что каждый пакет может хранить свои настройки в отдельном файле.
Любой пакет может записать свой конфигурационный файл планировщика в эту директорию. Рекомендуется чтобы имя файла совпадало с именем пакета, оно может содержать символы в верхнем и нижнем регистре, цифры, символы подчерты и тире.
Обычно скрипты добавляются в пакет с помощью дополнительного тега Source(SourceN). Они устанавливаются в секции %install и затем перечисляются в секции %files. Также желательно отметить эти файлы макросом %config, так как пользователь может пожелать изменить их.
Пример взят из пакета awstats:
Source4: cron.d.awstats
[...]
%install
[...]
install -d -m 755 $RPM_BUILD_ROOT/etc/cron.d
install -m 700 %{SOURCE4} $RPM_BUILD_ROOT/etc/cron.d/awstats
[...]
%files
[...]
%config /etc/cron.d/awstats
Конфигурационный файл /etc/cron.d/awstats выглядит примерно так:
#update reports every 6 hour 0 */6 * * * root /usr/sbin/awstats-update
Другое интересное решение используется в пакете mailman. Конфигурационный файл для cron'а включен в архив исходных кодов и устанавливается с помощью make install. Главное отличие здесь в том, что конфигурационный файл по умолчанию не используется. Он устанавливается в /usr/lib/mailman/cron/crontab, а в /etc/init.d копируется при запуске сервиса, при остановке - удаляется. Подобный способ используется потому что задания для cron'а являются частью функциональности сервиса, и не должны выполнятся если сервис не запущен.
Часть скрипта инициализации /etc/init.d/mailman:
ETC_CT=/etc/cron.d/mailman
MM_CT=/usr/lib/mailman/cron/crontab
MM_CTRL=/usr/lib/mailman/bin/mailmanctl
MM_PID=/var/lib/mailman/data/master-qrunner.pid
[...]
case "$1" in
start)
echo -n "Starting mailman"
if ! /sbin/checkproc -k -p $MM_PID /usr/bin/python; then
install -m 0644 $MM_CT $ETC_CT
$MM_CTRL --quiet --stale-lock-cleanup start
else
rc_reset
fi
rc_status -v
;;
stop)
echo -n "Shutting down mailman"
rm -f $ETC_CT
/sbin/killproc -p $MM_PID -TERM /usr/bin/python
rc_status -v
;;
Часть конфигурационного файла предназначенного для копирование в /etc/cron.d:
# # if you want to make changes to this file, please modify # /usr/lib/mailman/cron/crontab and restart mailman # # At 8AM every day, mail reminders to admins as to pending # requests. They are less likely to ignore these reminders if # they're mailed early in the morning, but of course, this is # local time... ;) 0 8 * * * mailman /usr/bin/python -S /usr/lib/mailman/cron/checkdbs # # At 9AM, send notifications to disabled members that are due # to be reminded to re-enable their accounts. 0 9 * * * mailman /usr/bin/python -S /usr/lib/mailman/cron/disabled [...] # At 3:27am every night, regenerate the gzip'd archive file. Only # turn this on if the internal archiver is used and # GZIP_ARCHIVE_TXT_FILES is false in mm_cfg.py 27 3 * * * mailman /usr/bin/python -S /usr/lib/mailman/cron/nightly_gzip [...]
Ссылки
| 7. Скрипты инициализации | 9. Меню рабочего стола |
|
Эта статья является незавершенной! Эта статья нуждается в доработке. Если Вы можете помочь, сделайте это в соответствии с руководством по оформлению. |