CronTabManager - изнутри

Что умеет CronTabManager?

В заметке добавлю видео о том как работать с компонентом на тему:

Настройка директории для PhpStorm:
Создание контроллера выполняющего какое то действие:
Создание контроллера для получения коллекции объектов:
Лог запусков:
Изюминка: отчет админу о неудачных заверениях:

И к видео немного текст… чтобы было интересней

Настройка директории для PhpStorm && Создание контроллера выполняющего какое то действие

Ничего не обычного, всего лишь скачивание demo контроллера и назначение директории как Sources Root с добавление своего кода в контроллер, создание задания на запуск раз в минуту и с просмотром как отлаживать:

Создание контроллера для получения коллекции объектов

В контроллерах есть возможности выборки, аналог процессоров getlist.

Логика работы логов

Если в задании, достигнуто указанное количество сообщений, у которых метка о завершении не установлена.

Это считается: не удачными попытками завершения задания!

Контроллер при каждом запуске проверят, был ли достигнут лимит в указанное количество не удачных попыток. И если лимит привешен, то администратор, получит уведомление на email.

Изюминка: отчет админу о неудачных заверениях

Чувствуете прелесть? Вас не будет засыпать кучей сообщений которые приходят каждую минуту)
Вы сами можете установить время когда и как присылать уведомления.

Зачем это нужно?
Представим, что есть сервис, который может не отвечать к примеру в течении часа. Вы уже об этом знаете, и тысячу раз убедились что он так работает.
Да к вот: вы ставите время запуска и количество неударных попыток к примеру 5.
Если 3 попытки были не удачными. А на четверную достигнут успех, то на 5 попытку вам не придет уведомление)))

Чтобы вызвать не завершенность задания нужно всего лишь вызвать
exit die

а еще задания можно блокировать прям из писем, чтобы оно вам нервы не трепало, из-за неудачных попыток)

Андрей Степаненко

06 марта 2020, 21:49

1 315

Поблагодарить автора Отправить деньги

Комментарии: 4

Станислав

02 июля 2021, 15:25

Я, видимо, буду первый :-)
В первую очередь огромное спасибо, компонент в идее очень полезный, например у меня много данных пишутся в базу в кроне из под ПУ VDS и управлять заданиями сразу из modx очень удобно. А у вас еще и расширенный функционал. И я в это дополнение по описанию практически влюбился. Но куда ж без ошибок:
при попытках включить даже демо
components/crontabmanager/lib/crontab/CrontabManagerManualFile.class.php 16
PHP warning: file_put_contents(/var/----/scheduler/crontabs/): failed to open stream: ��
[Crontab] Не удалось записать
*/1 * * * * /usr/bin/php7.0 /var/ -...- /scheduler/ControllersLinks/demo.php > /var/------/scheduler/logs/task_id_1_demo.log 2>&1 # t0kc9y

Я так понимаю, что нужно где-то копать в права, осталось только понять — где :-) в github у вас «Для работы необходимо чтобы на хостинге был доступ к функциями: system и passthru для запуска из под php» хотя в кроне ПУ plesk все работает

Далее не совсем понятно структура и принцип вызова) например в обычном режиме я подгружаю класс modx, далее $modx = new modX(); и впоследствии оперирую уже $modx? как пример

if(!$q = $modx->prepare($s)){
                $modx->log(MODX_LOG_LEVEL_ERROR, 'Ошибка выполнения запроса '.$s.' : '.$q->errorInfo()[0].'->'.$q->errorInfo()[1].'->'.$q->errorInfo()[2]);
            }

Я это делаю, потому что когда крон сервера запускает php файл, он не знает про modx ничего.
У вас в demo.php, тот же лог, вызывается как

$this->modx->log(modX::LOG_LEVEL_ERROR, "Задание завершено");

получается основной класс загружен я и должен заменить все свои $modx на $this->modx? Но как крон узнает, что такое modx? не замедлит ли это работу?

Потом не совсем понятна структура, основные файлы для крона должны лежать в schelduer\controllers
ControllersLinks — он сам создает, как я понял, при запуске
а вот папка tests и в ней demotests.php и frontend — это зачем и мне нужно создавать свои при создании своих задач?

Очень надеюсь разобраться и наладить работу, ибо компонент не просто шикарен, а ультрамегасупершикарен

Станислав

02 июля 2021, 15:47

Я так понимаю, что ошибки могут быть из-за ограничений безопасности modsecurity, а какие могут быть влиять, чтобы я их отключил?

Станислав

02 июля 2021, 18:51

Вновь прошу прощения, оказывается у меня все работает при выставлении параметра crontabmanager_handler_class в значение CrontabManagerHandler в настройках. Примеры запускаются и становятся активными, правда не выключаются, если выключить demo задание, то будет

[Crontab] $jobSpec must be crontab compatibile entry

а если создать свое с одной строчкой записи в лог, как в демо, то

PHP warning: preg_match(): Unknown modifier 'n'

и такое же

[Crontab] $jobSpec must be crontab compatibile entry

Станислав

07 июля 2021, 01:17

Итак, вернусь. Проблема была в следующем: задания в крон ставились, выполнялись, но при выключении или удалении возникала эта ошибка:

[Crontab] $jobSpec must be crontab compatibile entry

(к слову сказать в слове compatibile ошибка (compatible)). Ввиду того, что дискуссия ни с кем так и не началась, а писать автору мне было стыдно и неловко (т.к. компонент бесплатен и пока что мне нечего предложить взамен), я начал делать диагностику всего. В первую очередь права — как известно многие ПУ, в частности PLESK для крона выдают bash (chroot) или как-то так, только внутри области пользователя. Точнее когда системный пользователь «видит» только в тех пределах, где расположен сайт. Ок, тут расширил права в настройках, чтобы работал путь до php. Но это не повлияло. Я поискал где вообще возникает ошибка и за проверку переменной jobSpec выступают два файла, один из них — CronEntry.php. Вот тут и прятался ответ на задачу.
Добавив в лог ошибок значение переменной

if (!preg_match($regex, $jobSpec, $match)) {
            throw new \InvalidArgumentException($jobSpec.' -> -> -> '.'$jobSpec must be crontab compatible entry');
        }

я обнаружил, что переменная $jobSpec принимает значение MAILTO="" и дальше уже текст ошибки. Я проверяю «список заданий» и вижу, что те задачи, которые я ставил с панели управления сервера напрямую приобретают вид:

MAILTO=""
SHELL="/bin/sh"
*/1 * * * * /-----/php/7.3/bin/php -f 'httpdocs/path/file1.php'
* */2 * * * /-----/php/7.3/bin/php -f 'httpdocs/path/file2.php'

Когда же ставится задача с компонента, то он не прописывает все параметры, а просто

*/4 * * * * /------/php/7.3/bin/php /var/---/---/---.ru/httpdocs/core/scheduler/ControllersLinks/file1.php > /var/---/---/---.ru/httpdocs/core/scheduler/logs/task_id_14_File1.log 2>&1 # 6ounu4

Оказывается, что там (в файле) идет работа регулярного выражения, который берет строку и не понимает эти MAILTO и выдает ошибку.

$regex = '/^\s*(([^\s\#]+)\s+([^\s\#]+)\s+([^\s\#]+)\s+([^\s\#]+)\s+([^\s\#]+))\s+([^\#]+)(?:#(.*))?$/';

Чисто в теории если добавить\поменять\переписать добавив ^[/*0-9a-z] где-то вначале, то он пропустит лишние строчки и считает именно запись задачи. Но к сожалению я не селен в регулярки и изучение примеров ни к чему меня не привели. (а упростив проверку я вовсе «убил» все свои задания (обидно было)). Каюсь, регулярные приложения знать надо. Виню себя и ругаю.
Ну так вот, когда я «зачистил» все свои задачи поставленные напрямую с панели управления vds и добавил их только с панели управления компонента, то все стало работать. И удаление, и выключение, и включение (правда иногда через раз не включается) да и при нажатии на кнопку «список заданий» выводится список без дополнительных параметров.
Поэтому, если автор вдруг это прочитает, то по идее нужно поправить в условии $JobSpec регулярное выражение, чтобы оно пропускало что-то не типичное для себя и забирала исключительно формат классической задачи. Если нет, придется изучать регулярки :-( Так как я боюсь, что возможно нужно будет что-то добавить с панели управления сервера (какие-нибудь ротации или чистки куша) да и не проверил компонент полностью, если прописать в настройках все параметры уведомлений.
Еще раз — компонент классный, одной только проверкой на количество неудачных запусков. Еще раз простите за беспокойство.

Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.