Offline

Материал из Eludia.

Естественной средой исполнения для intranet-приложения является WEB-сервер. Однако некоторые операции с данными должны производиться вне всякой связи с наличием запросов от пользователей: скажем, перидическая подгрузка данных из внешних источников или архивация данных.

Такие действия естественно реализовывать в виде отдельных скриптов, исполнение которых инициируется cron или каким-то иным внешним механизмом.

Как использовать

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

• конфигурация;
• соединение с БД;
• API;
• код приложения.

Всё это обеспечивается размещением скрипта в директории lib/offline и преамбулой:

use Eludia::Offline;

Впрочем, такой способ сейчас является устаревшим. Лучше не упоминать явно этот модуль в теле скрипта, а подключить в командной строке:

perl -I... -MEludia::Offline /.../lib/offline/my_script.pl

Выглядит громоздко, но для повседневного использования легко автоматизируется, например, прописью в bashrc.

Блокировка от двойного запуска

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

Однако вероятностью такого события не стоит пренебрегать, особенно для периодически запускаемых скриптов, поскольку время исполнения может неожиданно затянуться.

Eludia::Offline автоматически отслеживает повторный запуск, однако только в том случае, когда в системе установлен модуль LockFile::Simple. При запуске производится попытка создать и заблокировать временный файл. Если такой файл уже создан и заблокирован действующим процессом, то исполнение прерывается, а в STDERR пишется соответствующее сообщение.

Автоматическая пропись в crontab

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

Однако достаточно раз и навсегда разместить в <Perl>-секции httpd.conf ($preconf) фрагмент вида:

schedule => {

 crontab => '/var/spool/cron/crontabs/root', # размещение crontab-файла

 command => '/etc/init.d/cron restart',      # команда перезапуска cron
			
},

и можно будет использовать в периодических скриптах псевдокомментарии, начинающиеся со строки #@crontab:

#@crontab */10 * * * *                       # это значит "каждые 10 минут"

При загрузке ядра производится сканирование всех offline-директорий приложения на предмет скриптов с такими пометками и их пропись в crontab. При этом параметр -I определяется по пути загружаемой в данный момент инсталляции ядра, а весь вывод STDOUT и STDERR направляются в log-файл, соответствующий данному скрипту.

Строго говоря, прописывать эти интервалы константами не совсем верно. Такие вещи по-хорошему должны задаваться не в программном коде, а в параметрах текущей инсталляции, то есть в $preconf. Нет проблем:

#@crontab */$preconf->{ten} * * * *

или, если серьёзно,

#@crontab $preconf->{my_parameters_section}->{my_parameter_name}

Строки crontab, содержащие упоминания несуществующих скриптов в offline-директориях, отключаются путём комментирования. Однако удаление crontab-комментария из скрипта не приведёт к его автоматическому отключению: проверяется только существование файла. Имеется в виду, что скрипт мог быть внесён в crontab вручную — тогда он должен по-прежнему исполняться.