Crontab path to php

Добавление PHP скрипта в cron

Cron — это демон (программа, которая постоянно работает в системе в фоновом режиме), представляющий собой планировщик задач в UNIX-подобных операционных системах, который в определенное время автоматически выполняет задания. Пример задания — регулярное создание резервной копии.

Каждый пользователь сервера может добавлять свои задания, указывая, в какое время и какие скрипты нужно выполнять от его имени. Задания могут выполняться, например, раз в день, раз в месяц, раз в год.. На вашем хостинге могут действовать ограничения на общее количество заданий и на то, как часто может выполняться задание (Например, не чаще 1 раза в 10 минут и не более 10 cron-заданий).

Структура крон задания

Задание (таблица crontab) включает 6 разделов, разделяемых пробелами или табуляцией.

минуты часы день_месяца месяц день_недели команда

Первые пять разделов задают время выполнения скрипта:
минуты: 0-59
часы: 0-23
день месяца: 1-31
месяц: 1-12
день недели: 0-7 (0 и 7 — воскресенье)
* — диапазон с первого до последнего.

команда задает скрипт, который нужно выполнять, например, скрипт на php. Если команда передает текст в стандартный вывод, этот текст отправляется на e-mail пользователя, но стандартный вывод можно перенаправить в /dev/null:

Примеры задания времени выполнения скрипта:
0 22 * * * — каждый день в 22:00 (в 0 минут, в 22 часа, каждый день, каждый год, каждый день недели)
0 0 1 * * — раз в месяц (в 0 минут 0 часов первого числа каждого месяца)
0,30 10-22 * * * — каждые полчаса между 10:00 и 22:00 (в 0 и 30 минут с 10 до 22 часов каждый день)
*/10 * * * * — каждые 10 минут

Онлайн генератор crontab для PHP скрипта

Чтобы выбрать несколько значений из списка, зажмите Ctrl.

Добавить скрипт PHP в крон

Для начала нам нужен SSH доступ к серверу или панель Cron у вашего хостера. Настройки крон в панели у каждого хостера свои, их разбирать нет смысла.

Разберем действия через SSH.

PHP скрипты в терминале запускаются с помощью команды

Эту команду уже можно добавить в крон, но тут могут появиться проблемы

При сохранении сокращенной версии команды, PHP может быть не найден

Не стоит добавлять в крон команду php. Воспользуйтесь запуском whereis php и скопируйте полную версию команды, чаще всего это /usr/bin/php

Далее вместо команды php, лучше сразу всё проверять на полной версии. Например:

HTTP сервер и команда из терминала могут запускать разные версии PHP

Чтобы проверить, что версия одна создайте на сервере файл с контентом:

Запустите его из браузера. Увидите какую версию запускает веб сервер.

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

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

Если версии разные, то надо поискать команду запуска версии PHP как у веб сервера. Вам может помочь команда whereis.

Вот у нас запуск php выводит 5.6, а нам надо 7.1. Получается надо запускать /usr/local/bin/php7.1

HTTP сервер и команда из терминала могут запускать PHP с разными настройками

У разных CMS есть свои обязательные настройки. Какие настройки изменятся и как это повлияет в вашем конкретном случае — не знаю. Чтобы узнать значение настройки — используйте функцию ini_get(), чтобы в терминале указать параметр — используйте директиву -d.

Например, нам надо верно установленный часовой пояс. Контент тестового файла:

Запускаем без параметров, и с установленным часовым поясом:

Важно: если параметры у вас не верные и на веб сервере и в терминале — надо настраивать сам PHP, например через php.ini. Если проблема только при запуске через консоль — тогда можно использовать установку нужных параметров с помощью параметра -d.

Пользователь, от которого работает веб сервер, может отличаться от текущего.

Задание в крон добавляется от того пользователя, от кого вы работаете в SSH. А вебсервер может работать от другого лица.

Создайте файл с контентом:

Запустите его из браузера. Посмотрите на сервере в папке скрипта владельца файла test.txt. После этого файл test.txt удалите, запустите скрипт через консоль. Снова посмотрите владельца файла test.txt. В первом и втором случае — это должен быть один и тот же пользователь.

При запуске через терминал не установлены некоторые переменные.

Часто скрипт зависит от установки $_SERVER[‘DOCUMENT_ROOT’]. В этой переменной хранится корневая папка сайта. А когда мы запускаем скрипт через консоль — никакого сайта нет. Файл мы можем хоть откуда запускать, сайт не требуется для этого.

Чтобы решить эту проблему, в начало файла добавьте определение переменной:

Если скрипт находится в корневой папке сайта — используйте константу __DIR__, в ней папка, которой находится запускаемый файл. Если скрипт в других папках, то можно использовать относительные пути от __DIR__:

Добавление крон

С основными ошибками закончили, приступим к делу!

Чтобы запустить файл, нужен полный путь к нему. Для этого перейдите в папку с файлом, и введите команду pwd, скопируйте путь.

Как запускать php определились выше, путь к файлу есть. Попробуем запустить самостоятельно с полными путями и полной командой. Всё работает:

Берем команду и вставляем её в генератор, настраиваем время, жмем создать. Получаем строку по типу 1 1,13 * * * /usr/bin/php /var/www/myscript.php — это запуск php скрипта 2 раза в день.

Для редактирования крон заданий существует команда crontab -e. Введите её в терминале и добавьте в самый низ полученную ранее строку, сохраните.

Важно: после последнего задания должна быть одна пустая строка, иначе работать не будет. Так устроен крон.

Чтобы просмотреть список заданий, используйте команду crontab -l.

Настройка уведомлений о работе крон на электронную почту

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

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

Источник

Запуск PHP скрипта по расписанию cron. Когда не всё так ясно

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

Немного теории по этим ссылкам: тут и тут, для тех хочет освежить память.

Случай первый

В настройках операционной системы не указаны пути по умолчанию. Как следствие следующая команда в cron не будет выполнена.

php /var/www/LOGIN/data/www/SITE/cron.php 

Правильной командой будет второй вариант, где мы пропишем полный путь до интерпретатора php.

/usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php 

Есть ещё несколько способов запуска php скрипта описанных здесь. Интересным будет здесь то, что php скрипт запускается как файл с командами для консоли и тут можно написать целую тучу команд и описать всевозможные варианты на любой вкус. Код выглядит так.

В команде для выполнения в cron прописывается путь к скрипту и только. В скрипте ставятся символы #!, а дальше просто пишем нужные нам команды на языке bash.

Случай второй

Выполнение скрипта при запросе из браузера приводит к выводу страницы в браузер. А при выполнении скрипта через cron приводит к выводу текста страницы в командную строку. Тут может быть несколько вариантов. Система может быть настроена на сохранение результатов вывода в консоль в виде файла. Причем файл этот может размешаться не в самом типичном месте. Постепенно это может забить всё пространство на диске. Часто под сайт дают место в 1 Гигабайт, 500 мегабайт. И даже встречались хостинги с 50 и 10 мегабайт под сайт.

Как вариант, вывод может быть перенаправлен на почтовый ящик, который заботливый хостер ненавязчиво подарил вам и прописал в настройках хостинга как email по умолчанию. При каждом выполнении скрипта весь текст, выводящийся в консоль, будет оформлен в письмо. Проблемы могут начаться неожиданно. Если задание cron выполняется часто, а у почты хостинга прописано ограничение на количество писем в день, почта просто ляжет (заблокируется провайдером как потенциальный спамер). И как неприятные последствия вы получите отказ в регистрации пользователей, уведомление пользователей и д.р., что подвязано на почту.

Решение старо как мир. Нужно сделать перенаправление вывода из консоли в пустоту. Делается это добавлением команды в конце команды крона.

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

Случай третий

Ситуация проста. Нужно отладить скрипт, запускаемый планировщиком. Можно попытаться сделать это средствами php, заставлять скрипт писать логии и т.п. Но есть способ куда проще, нужно перенаправить вывод в файл. Команда проста, дополнительный параметр к нашей команде:

> /var/www/LOGIN/data/www/SITE/log.html 

Её надо добавить в конце команды:

/usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html 

Знак «>» указывает системе о перенаправлении вывода. Далее имя файла. В нашем случае указан абсолютный путь. Этот пример не составляет труда найти в интернете. Но тут нас может поджидать неприятность, вытекающая из второго случая. Заботливый хостер автоматически добавляет перенаправление вывода в конце нашей строки. И иногда маскирует это. В итоге получается команда вида:

/usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html >/dev/null 2>&1 

В итоге вывод снова перенаправлен в пустоту и выходной файл будет пуст. Тут хостеру можно указать на его ошибку, что он уж слишком перехитрил с настройками. А можно сразу воспользоваться костылём. После команды перенаправления в файл закончить команду символами &&. Эти два символа используются в командной строке для объединения нескольких команд в одной строке. Они дают командной строке понять, что команда окончена и дальше идет следующая команда. К ней и применяется перенаправление в пустоту. В итоге и перенаправление в пустоту осталось и лог файл записан верно. Пример команды:

/usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html && >/dev/null 2>&1 

Случай четвёртый

Скрипт запустился, но работает не верно. Причиной тому — интерпретатор php при запуске из командной строки начинает работать в неправильно настроенном окружении, отличным от того, которое было бы при запуске через HTTP-сервер. Первый признак – скрипт не находит файлы, которые лежат с ним в одной директории, а начинает считать себя расположенным в корневой директории пользователя, которая на несколько папок выше чем корень сайта. Первое, что нужно проверить – переменное окружение и супер глобальный массив $_SERVER.

Первое, что находишь в интернете по этой проблеме – совет прописать в кроне команду смены директории:

cd /var/www/LOGIN/data/www/SITE/ 

Но в каких-то случаях это не помогает. Выход есть. Один из них взять всё в свои руки и задать недостающее окружение для работы скрипта. Информации про это в интернете уже больше.

Иногда просто хватает вписать следующий код в начале скрипта и пути снова становятся рабочими.

$path_parts = pathinfo($_SERVER['SCRIPT_FILENAME']); // определяем директорию скрипта chdir($path_parts['dirname']); // задаем директорию выполнение скрипта 

Как видите, всё прописано функциями и утруждаться настройками не надо.

Заключение

На этом всё. Проблемы и решения не тривиальны и вообще такое сочетание неудачных настроек встречается редко. Удачи вам при развертывании своих проектов и при переездах.

Источник