Linux cron запуск php скрипта

Настройка и запуск cron на веб-сервере

Cron — это программное обеспечение для настройки автоматического выполнения заданий (скриптов) в Unix/Linux подобных системах: Centos, Debian, Ubuntu и других. Этот планировщик задач работает аналогично во всех версиях операционных систем.

Добавить скрипт в Cron можно через специальный файл «crontab», содержащий список заданий для выполнения.

Пример пустого файла crontab

Как задавать время в Cron

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

• минута (0-59);
• час (0-23);
• день (1-31);
• месяц (1-12);
• день недели (0-6);
• путь к исполняемому файлу.

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

Пример

Строка следующего вида подразумевает выполнение команды каждый день в 7 утра и 7 вечера:

Настройка Cron в ISPmanager

Настроить Cron на хостинге проще всего через панель управления. Для примера разберем как производится настройка планировщика в ISPmanager 4.

1. Открываем панель управления ISPmanager и переходим в «Планировщик» в разделе «Главное». Далее создаем новое задание, нажимая на кнопку «Создать».
   
2. Заполняем поля в открывшемся редакторе и нажимаем «ОK»:

• Команда — здесь указываем полный путь (директорию) к исполняемому файлу программы или готовому рабочему скрипту.
• Описание — по желанию можно добавить краткое описание выполняемого задания.
• Расписание— добавляем расписание с возможностью выбора режима. Режим «Базовый» — с выбором доступных вариантов и «Экспертный» — самостоятельная настройка.

1. Eсли есть возможность, нужно настроить получение отчетов по запуску заданий на почтовый адрес пользователя. Для этого открываем «Планировщик» → «Настройки» → «Адрес e-mail» и указываем адрес почты для получения. После чего нужно убедиться, что в настройках не стоит галочка напротив «Не отправлять отчет по e-mail».

Настройка Cron для запуска PHP-скрипта

В некоторых случаях бывает так, что автоматическое выполнение PHP-скрипта невозможно. Чаще всего подобные ошибки случаются при запуске PHP-скрипта через локальный интерпретатор. В таких случаях требуется запустить Cron вручную, для чего лучше всего использовать программу wget. В приведенном ниже примере «example.com» нужно заменить на реальный путь к вашему PHP-файлу.

Полезные примеры

Разберем уже приведенный выше пример, немного изменив параметры:

Запуск PHP-скрипта будет происходить в 7:00 и 19:00 каждого воскресенья и 3 числа каждого месяца (совпадения дня недели и числа не имеют значения).

/dev/null/2>&1 — эта команда Cron добавляется в конце сценария (строки), для выполнения скрипта в фоновом режиме без уведомлений.

Помимо этого, можно добавлять другие полезные опции в конце строки планировщика Cron. Как например, для отладки запускаемого скрипта, нужен лог-файл выполнений.

То есть, если мы хотим настроить вывод результатов запуска задания Cron в определенный файл, можно изменить команду следующим образом:

Просмотрев такой лог, можно понять причину, почему Cron не выполняет скрипт.

Начни экономить на хостинге сейчас — 14 дней бесплатно!

Источник

Запуск php-скрипта в cron

Доброго дня. Столкнулся с такой проблемой: есть php-скрипт, который должен обновляться по крону и обновлять сведения на локальном сайте. Сделал так

в /var/log/syslog пишет

Если запустить скрипт через терминал? Выполняется ?

sudo php /var/www/html/site/check.php

Попробуй просто запускать скрипт тем пхп, что работает в консоли.

ошибка же падает. Зачем с под судо запускать ?

нет функции oci_connect() в php cli.

тогда выдает так

в www-data нет доступа к этим папкам.

Можете: а) Дать права 777 для проекта. б) Изменить владельца для проекта. в) Или добавить своего пользователя в группу www-data.

Не используй для консоли cgi интерпретатор.

Реши проблемы с путями и доступом к ним — скрипт не имеет прав на чтение файла.

Странно,OCI8 библиотеку с oracle client ставил, связь с бд была — об этом сигналила внутренняя проверка.. Тогда почему через браузер все норм выполняется, мне вообще не понятно

Включи это расширение для CLI-пыхи — там разные конфиги

я пробовал и не через cgi, а /usr/bin/php /usr/bin/php7.0 или просто php, все одно и то же

Потому что в браузере работает пхп для браузера. В консоли пхп для консоли с своими конфигами.

Расскоментил в /etc/php/7.0/cli/php.ini и заодно в /etc/php/7.0/apache2/php.ini extension=php_oci8_12c.dll

Добавил текущего юзера в www-data www-data:x:33:testuser

В /etc/apache2/envvars добавил
export LD_LIBRARY_PATH=/usr/lib/oracle/12.2/client/lib/

Перезапустил апач и все равно

А теперь рассказывай, откуда такие веселые пути.

Так запускай его в корне через curl, например

Правильно ли понимаю, что такого файла не должно быть в линуксе php_oci8_12c.dll , а должен быть с расширением *.so ? В php.ini есть параметр extension-dir — это путь для динамически подгружаемых библиотек, и собственно оттуда и должен браться php_oci8_12c ? Но по какой-то причине такого файла в системе нет, хотя по логике его должна была создать установка через pecl или через пакеты из instant oracle client. Или я то-то опять упускаю.

dll быть не должно

А еще ты можешь посмотреть в конфиге, используемом для веб-версии(я не знаю, что у тебя там) и сделать для cli аналогично.

Пришлось качать и компилить отдельно oci8.so

потом в /etc/php/7.0/cli/php.ini отдельно прописал extension_dir = /usr/lib/php/20151012/

Погрепай конфиги же на предмет имени этого файла.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Настройка Cron

Системным администраторам, да и обычным пользователям часто приходится автоматизировать различные задачи по обслуживанию и работе с Linux с помощью скриптов. Это очень удобно, вы просто запускаете скрипт, и он делает все что необходимо без вашего вмешательства. Следующий шаг в этом пути — настроить автоматически запуск нужного скрипта в нужное время.

Именно для этих задач в Linux используется системный сервис cron. Это планировщик, который позволяет выполнять нужные вам скрипты раз в час, раз в день, неделю или месяц, а также в любое заданное вами время или через любой интервал. Программа часто используется даже другими службами операционной системы. В этой статье мы рассмотрим как выполняется настройка Cron и разберем основные часто используемые примеры.

Как работает Cron?

Фактически, Cron — это сервис, как и большинство других сервисов Linux, он запускается при старте системы и работает в фоновом режиме. Его основная задача выполнять нужные процессы в нужное время. Существует несколько конфигурационных файлов, из которых он берет информацию о том что и когда нужно выполнять. Сервис открывает файл /etc/crontab, в котором указаны все нужные данные. Часто, в современных дистрибутивах там прописан запуск утилиты run-parts, которая запускает нужные скрипты из следующих папок:

• /etc/cron.minutely — каждую минуту;
• /etc/cron.hourly — каждый час;
• /etc/cron.daily — каждый день;
• /etc/cron.weekly — каждую неделю;
• /etc/cron.monthly — каждый месяц.

В этих папках должны находиться скрипты, которые нужно выполнять с указанным интервалом. Скрипты должны иметь права на выполнение и их имя не должно содержать точки. Это очень сильно облегчает работу с планировщиком для новых пользователей. Также в файле crontab прописан запуск команды anacron, которая работает так же как и cron, только предназначена для задач, которые нужно выполнять раз в длительный период, например, раз в день, неделю, месяц, год.

Она позволяет выполнять их даже если компьютер работает не всегда и время от времени выключается. Дата выполнения задания последний раз записывается в файл /var/spool/anacron, а затем, при следующем запуске anacron проверяет был ли запущен нужный процесс в нужное время, и если нет, то запускает его. Сам же сервис cron больше рассчитан на выполнение задач в течение дня или с точно расписанным временем и датой.

Настройка Cron

Для настройки времени, даты и интервала когда нужно выполнять задание используется специальный синтаксис файла cron и специальная команда. Конечно, вы всегда можете отредактировать файл /etc/crontab, но этого делать не рекомендуется. Вместо этого, есть команда crontab:

Ее всегда желательно выполнять с опцией -e, тогда для редактирования правил будет использован ваш текстовый редактор по умолчанию. Команда открывает вам временный файл, в котором уже представлены все текущие правила cron и вы можете добавить новые. После завершения работы команды cron файл будет обработан и все правила будут добавлены в /var/spool/cron/crontabs/имя_пользователя причем добавленные процессы будут запускаться именно от того пользователя, от которого вы их добавляли.

Поэтому тут нужно быть аккуратным, и если вам нужно выполнять скрипты от рута, то и crontab нужно выполнить от рута, а не от пользователя. Это часто становится причиной проблем.

Синтаксис crontab

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

минута час день месяц день_недели /путь/к/исполняемому/файлу

Нужно сказать, что обязательно нужно писать полный путь к команде, потому что для команд, запускаемых от имени cron переменная среды PATH будет отличаться, и сервис просто не сможет найти вашу команду. Это вторая самая распространенная причина проблем с Cron. Дата и время указываются с помощью цифр или символа ‘*’. Этот символ означает, что нужно выполнять каждый раз, если в первом поле — то каждую минуту и так далее. Ну а теперь перейдем к примерам.

Примеры настройки cron

Сначала можно посмотреть задачи cron для суперпользователя, для этого можно воспользоваться опцией -l:

Вы можете удалить все существующие задачи командой -r:

Давайте предположим, что нам нужно запускать от имени суперпользователя наш скрипт по адресу /usr/local/bin/serve. Какой-нибудь обслуживающий скрипт. Самый простой пример — запускать его каждую минуту:

Далее, усложним, будем запускать каждый час, в нулевую минуту:

Запускаем в нулевую минуту нулевого часа, каждый день, это в 12 ночи:

0 0 * * * /usr/local/bin/serve

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

0 0 1 * * /usr/local/bin/serve

Можно в любой день, например, 15 числа:

0 0 15 * * /usr/local/bin/serve

В первый день недели первого месяца года, 0 часов 0 минут:

0 0 * 1 0 /usr/local/bin/serve

Или в нулевой день недели каждого месяца:

0 0 * * 0 /usr/local/bin/serve

Вы можете выбрать любую минуту, час и день недели, например, 15.30 во вторник:

30 15 * * 2 /usr/local/bin/serve

Понедельник считается первым днем, воскресенье — это седьмой или нулевой день. Еще можно писать сокращенное название дня недели, например sun — воскресенье:

30 15 * * sun /usr/local/bin/serve

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

0 7-19 * * * /usr/local/bin/serve

Если нужно запустить команду несколько раз, можно использовать разделитель «,». Например, запустим скрипт в 5 и 35 минут пятого (16:05 и 16:35), каждый день:

5,35 16 * * * /usr/local/bin/serve

Вы можете захотеть не указывать отдельно время, а просто указать интервал, с которым нужно запускать скрипт, например, раз в 10 минут. Для этого используется разделитель косая черта — «/»:

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

• @reboot — при загрузке, только один раз;
• @yearly, @annually — раз год;
• @monthly — раз в месяц;
• @weekly — раз в неделю;
• @daily, @midnight — каждый день;
• @hourly — каждый час.

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

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

sudo vi /etc/corn.daily/basckup

Скрипт должен выглядеть подобным образом. Теперь вы знаете как настроить cron, осталось проверить как все работает.

Отладка работы

После того как вы настроили правила, еще хотелось бы проверить работают ли они. Для этого ждем того времени, когда скрипт уже должен быть выполнен и смотрим лог cron. Иногда он находится в /var/log/cron, а иногда пишется в syslog. Например, у меня в crontab есть такая строка:

Она должна выполняться в 19.40 каждый день, теперь смотрим лог:

grep CRON /var/log/syslog

И видим что в нашем логе она действительно есть и выполняется целиком успешно. Если бы были какие-либо ошибки, то тут же было бы выведено сообщение.

Если нужно проверить скрипт, который находится в одной из специализированных папок, то тут еще проще, просто запустите run-paths, передав ей в параметр нужную папку или даже сам скрипт:

sudo run-paths /etc/cron.daily/

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

Выводы

В этой статье мы рассмотрели как выполняется настройка cron для удобного планирования автоматических задач. Надеюсь, эта информация была полезной для вас.

Источник