CronTabManager - изнутри
Что умеет CronTabManager?
В заметке добавлю видео о том как работать с компонентом на тему:
Ничего не обычного, всего лишь скачивание demo контроллера и назначение директории как Sources Root с добавление своего кода в контроллер, создание задания на запуск раз в минуту и с просмотром как отлаживать:
В контроллерах есть возможности выборки, аналог процессоров getlist.
Если в задании, достигнуто указанное количество сообщений, у которых метка о завершении не установлена.

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

Чувствуете прелесть? Вас не будет засыпать кучей сообщений которые приходят каждую минуту)
Вы сами можете установить время когда и как присылать уведомления.
Зачем это нужно?
Представим, что есть сервис, который может не отвечать к примеру в течении часа. Вы уже об этом знаете, и тысячу раз убедились что он так работает.
Да к вот: вы ставите время запуска и количество неударных попыток к примеру 5.
Если 3 попытки были не удачными. А на четверную достигнут успех, то на 5 попытку вам не придет уведомление)))
Чтобы вызвать не завершенность задания нужно всего лишь вызвать
exit die
а еще задания можно блокировать прям из писем, чтобы оно вам нервы не трепало, из-за неудачных попыток)
В заметке добавлю видео о том как работать с компонентом на тему:
- Настройка директории для PhpStorm:
- Создание контроллера выполняющего какое то действие:
- Создание контроллера для получения коллекции объектов:
- Лог запусков:
- Изюминка: отчет админу о неудачных заверениях:
Настройка директории для PhpStorm && Создание контроллера выполняющего какое то действие
Ничего не обычного, всего лишь скачивание demo контроллера и назначение директории как Sources Root с добавление своего кода в контроллер, создание задания на запуск раз в минуту и с просмотром как отлаживать:
Создание контроллера для получения коллекции объектов
В контроллерах есть возможности выборки, аналог процессоров getlist.
Логика работы логов
Если в задании, достигнуто указанное количество сообщений, у которых метка о завершении не установлена.

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

Изюминка: отчет админу о неудачных заверениях
Чувствуете прелесть? Вас не будет засыпать кучей сообщений которые приходят каждую минуту)
Вы сами можете установить время когда и как присылать уведомления.
Зачем это нужно?
Представим, что есть сервис, который может не отвечать к примеру в течении часа. Вы уже об этом знаете, и тысячу раз убедились что он так работает.
Да к вот: вы ставите время запуска и количество неударных попыток к примеру 5.
Если 3 попытки были не удачными. А на четверную достигнут успех, то на 5 попытку вам не придет уведомление)))
Чтобы вызвать не завершенность задания нужно всего лишь вызвать
exit die
а еще задания можно блокировать прям из писем, чтобы оно вам нервы не трепало, из-за неудачных попыток)
Комментарии: 4
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
В первую очередь огромное спасибо, компонент в идее очень полезный, например у меня много данных пишутся в базу в кроне из под ПУ 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? как пример
Я это делаю, потому что когда крон сервера запускает php файл, он не знает про modx ничего.
У вас в demo.php, тот же лог, вызывается как
получается основной класс загружен я и должен заменить все свои $modx на $this->modx? Но как крон узнает, что такое modx? не замедлит ли это работу?
Потом не совсем понятна структура, основные файлы для крона должны лежать в schelduer\controllers
ControllersLinks — он сам создает, как я понял, при запуске
а вот папка tests и в ней demotests.php и frontend — это зачем и мне нужно создавать свои при создании своих задач?
Очень надеюсь разобраться и наладить работу, ибо компонент не просто шикарен, а ультрамегасупершикарен
а если создать свое с одной строчкой записи в лог, как в демо, то
и такое же
(к слову сказать в слове compatibile ошибка (compatible)). Ввиду того, что дискуссия ни с кем так и не началась, а писать автору мне было стыдно и неловко (т.к. компонент бесплатен и пока что мне нечего предложить взамен), я начал делать диагностику всего. В первую очередь права — как известно многие ПУ, в частности PLESK для крона выдают bash (chroot) или как-то так, только внутри области пользователя. Точнее когда системный пользователь «видит» только в тех пределах, где расположен сайт. Ок, тут расширил права в настройках, чтобы работал путь до php. Но это не повлияло. Я поискал где вообще возникает ошибка и за проверку переменной jobSpec выступают два файла, один из них — CronEntry.php. Вот тут и прятался ответ на задачу.
Добавив в лог ошибок значение переменной
я обнаружил, что переменная $jobSpec принимает значение MAILTO="" и дальше уже текст ошибки. Я проверяю «список заданий» и вижу, что те задачи, которые я ставил с панели управления сервера напрямую приобретают вид:
Когда же ставится задача с компонента, то он не прописывает все параметры, а просто
Оказывается, что там (в файле) идет работа регулярного выражения, который берет строку и не понимает эти MAILTO и выдает ошибку.
Чисто в теории если добавить\поменять\переписать добавив ^[/*0-9a-z] где-то вначале, то он пропустит лишние строчки и считает именно запись задачи. Но к сожалению я не селен в регулярки и изучение примеров ни к чему меня не привели. (а упростив проверку я вовсе «убил» все свои задания (обидно было)). Каюсь, регулярные приложения знать надо. Виню себя и ругаю.
Ну так вот, когда я «зачистил» все свои задачи поставленные напрямую с панели управления vds и добавил их только с панели управления компонента, то все стало работать. И удаление, и выключение, и включение (правда иногда через раз не включается) да и при нажатии на кнопку «список заданий» выводится список без дополнительных параметров.
Поэтому, если автор вдруг это прочитает, то по идее нужно поправить в условии $JobSpec регулярное выражение, чтобы оно пропускало что-то не типичное для себя и забирала исключительно формат классической задачи. Если нет, придется изучать регулярки :-( Так как я боюсь, что возможно нужно будет что-то добавить с панели управления сервера (какие-нибудь ротации или чистки куша) да и не проверил компонент полностью, если прописать в настройках все параметры уведомлений.
Еще раз — компонент классный, одной только проверкой на количество неудачных запусков. Еще раз простите за беспокойство.