Cron-задачи для PHP-скрипта

Cron — это то, что крутится без браузера. Письма из очереди, снятие просроченного VIP, пересчёт счетчиков, очистка временных файлов. Без cron сайт «в целом открывается», но часть функций дохнет тихо: «уведомления не приходят», «VIP висит вечно».

В комплекте скрипта обычно написано, какой URL или php-файл дергать и как часто. Ниже — как повесить это на shared и на VDS, чтобы реально выполнялось.

Что обычно ставят в расписание

• Очередь писем и уведомлений — раз в минуту или каждые 5 минут.
• Снятие просроченных платных услуг и публикаций.
• Очистка cache, старых сессий, временных загрузок.
• Обмен курсами / догрузка котировок — если продукт это умеет.
• Sitemap или служебные пересчёты ночью.

Не вешайте тяжёлый полный пересчёт каждую минуту «на всякий случай». Нагрузка вырастет, толку мало.

Путь к PHP

В cron нужен CLI-бинарник, не «сайт открылся в браузере». На shared путь часто:

/usr/bin/php
/opt/php82/bin/php
/usr/local/bin/php

Уточните в справке Beget/Timeweb/ISPmanager для выбранной версии. Важно: CLI должен быть той же ветки 8.x, что и сайт. Иначе веб на 8.2, cron на 7.4 — и ловите Parse error только в логе крона.

Проверка:

/usr/bin/php -v
/usr/bin/php /path/to/cron.php

Формат задания

Классика:

*/5 * * * * /usr/bin/php /var/www/site/cron/queue.php >> /var/log/site-cron.log 2>&1

Или вызов через wget/curl, если скрипт ждёт HTTP:

*/5 * * * * curl -fsS https://example.com/cron/secret-key >/dev/null

Секрет в URL или ключе обязателен — иначе боты будут дёргать задачу сами. Не светите ключ в публичных репозиториях.

Shared-панель

В панели «Планировщик» / Cron создаёте строку, указываете расписание и команду. Иногда интерфейс просит только URL — тогда используйте http-вариант из мануала продукта.

На shared часто:

• минимальный интервал — 5 минут, каждую минуту нельзя;
• нет доступа к системному crontab, только веб-форма;
• логи крона смотреть неудобно — пишите вывод в свой файл в домашнем каталоге.

VDS

crontab пользователя сайта или root (лучше пользователя сайта):

crontab -e

Права на файл задачи и путь — абсолютные. Относительные пути из cron ломаются: working directory не тот. Внутри PHP-скрипта тоже лучше абсолютные пути или правильный chdir в начале.

Если PHP через php-fpm пулы, CLI всё равно отдельный пакет php-cli. Без него cron не из чего запускать.

Как понять, что cron живой

1. Добавьте запись в лог в начале cron-скрипта.
2. Сделайте тестовый запуск руками из SSH теми же путями.
3. Проверьте эффект в продукте: письмо ушло, VIP снялся.

Тишина в логе при «вроде добавили в панель» — часто опечатка в пути или другой пользователь crontab.

Ошибки и окружение

В cron часто нет тех же переменных окружения, что в SSH-сессии. PATH короткий. Поэтому полный путь к php обязателен. Ошибки БД в крон-задачах те же: 1045, connection refused — см. ошибка базы.

Если задача дергает https URL, сертификат должен быть валидным, иначе curl -f упадёт. Про SSL: SSL на сайте.

Нагрузка

Не ставьте пять тяжёлых задач на одну и ту же минуту. Разнесите: очередь — каждые 5 минут, очистка — ночью, отчёты — раз в час. На слабом VDS параллельные php-cli сожрут RAM вместе с php-fpm и MySQL.

Требования к окружению: PHP/MySQL. Установка продукта: установка. Мониторинг «сайт жив, а крон нет» отдельно не заменит — но uptime главной всё же полезен: мониторинг.

Блокировки и наложеение запусков

Если задача раз в 5 минут иногда бежит 7 минут, получите параллельные запуски. Часть скриптов это переживает, часть плодит дубли писем и гонки в БД. Используйте flock:

*/5 * * * * flock -n /tmp/site-queue.lock /usr/bin/php /var/www/site/cron/queue.php

Не получилось взять lock — пропуск итерации. Это лучше, чем два тяжёлых импорта одновременно на 2 GB RAM.

Расписание глазами человека

Пять задач на минуту :00 — всплеск load average. Разнесите: очередь на */5, очистку на 15 3 * * *, пересчёт на 30 * * * *. На shared лимит одновременных процессов жёстче — не копируйте «как на мощном VDS».

Логи крона

Пишите stdout/stderr в файл с ротацией. Пустой файл две недели при «задача добавлена» — признак, что crontab другого пользователя или опечатка в расписании. На панели shared смотрите, под каким аккаунтом висит задание.

Ошибки вида SQLSTATE в логе крона лечатся так же, как в вебе: ошибка базы. После смены пароля БД обновите конфиг — веб уже работает с новым, а вы забыли, что CLI использует тот же файл (обычно да, но бывают отделные env).

HTTP-cron и защита

Если продукт даёт URL вида /cron.php?key=..., ключ длинный и не из словаря. Ограничьте доступ по IP в Nginx, если крон дергается только с localhost:

allow 127.0.0.1; deny all;

для location cron. Иначе сканеры найдут URL в access.log и будут долбить. Про Nginx: мануал.

Виндовс и локалка

На MicroServer полноценный cron Linux нет. Для локальной проверки запускайте php-файл вручную или через Планировщик заданий Windows. Боевые расписания настраивайте на сервере. Стек локалки: MicroServer.

Чеклист после выкладки

1. Список задач из readme продукта.
2. Путь к php той же версии, что веб.
3. Абсолютные пути.
4. Тестовый ручной запуск.
5. Запись в лог от планировщика.
6. Выключен старый cron после переноса — перенос.

Права на файлы задач: chmod. Общий сервер: VDS, root. Если сайт в целом 500 — сначала это: ошибка 500.

На ISPmanager и похожих панелях cron иногда включается галкой «URL» без вывода ошибок. Добавьте свой лог внутри php-задачи — иначе не увидите Fatal. После смены версии PHP в панели перепроверьте команду cron: путь /opt/php74/... мог остаться старым. Требования к версии: PHP/MySQL. Установка продукта с напоминанием про cron в конце: установка.