Cron — это планировщик, который запускает задачи на сервере по расписанию. На хостинге его используют для резервного копирования, рассылки уведомлений, обновления курса валют или очистки старых файлов. Проблема в том, что при ошибке cron молчит: задание просто не выполняется, и узнаёте вы об этом через несколько дней, когда замечаете отсутствие результата. Поэтому первое правило простое — направляйте вывод каждого задания в лог-файл, а затем проверяйте ошибки ниже по очереди.
Сначала направьте вывод в лог
Если добавить в конец команды перенаправление вывода, вы сможете потом прочитать, что сообщил скрипт. Оператор >> дописывает в файл, а 2>&1 отправляет туда же и сообщения об ошибках. Без этого «Fatal error» от PHP или системное «command not found» просто теряются.
*/15 * * * * /usr/bin/php /var/www/user/data/www/misol.uz/cron/kurs.php >> /var/www/user/data/logs/kurs.log 2>&1Чтобы лог не разрастался, периодически очищайте его или пишите в него только важные строки. Теперь разберём сами ошибки.
1. Использован относительный путь
Когда вы открываете скрипт в браузере, он работает из своей папки, а cron запускает его из домашнего каталога пользователя. Поэтому относительные пути вроде include 'config.php' или file_put_contents('data/out.txt', ...) указывают в другое место, и файл не находится. Решение — использовать в PHP константу __DIR__ или сначала переходить в нужную папку прямо в команде.
*/15 * * * * cd /var/www/user/data/www/misol.uz && /usr/bin/php cron/kurs.php >> /var/www/user/data/logs/kurs.log 2>&12. Короткий PATH в окружении cron
Команды php, wp или composer, которые работают в терминале, внутри cron могут выдать «command not found». Причина в том, что cron стартует с минимальным набором переменных окружения и не загружает ваши настройки оболочки. Всегда указывайте полный путь к программе; узнать его можно командой which php.
3. Не та версия PHP
На хостинге часто установлено несколько версий PHP. Сайт в панели может работать на PHP 8.2, а простая команда php в cron вызывает старую системную версию — и скрипт с современным синтаксисом сразу падает с «syntax error». Укажите точный путь к нужной версии и проверьте его:
/opt/php82/bin/php -vПути к версиям отличаются от сервера к серверу, поэтому уточняйте их в панели или у техподдержки.
4. Нет права на выполнение или испорчены концы строк
Если скрипт вызывается в cron напрямую (например, /home/user/backup.sh), у файла должно быть право на выполнение. Кроме того, bash-скрипт, отредактированный в Windows, сохраняет символы CRLF в конце строк, и Linux отвергает его с ошибкой «bad interpreter».
chmod +x /home/user/backup.sh
sed -i 's/\r$//' /home/user/backup.sh5. Неэкранированный символ процента
Малоизвестная, но очень частая ошибка. В строке crontab знак % означает перевод строки, поэтому команда вроде date +%Y-%m-%d разрезается на части. Ставьте обратную косую черту перед каждым процентом: date +\%Y-\%m-\%d. Сложные команды удобнее вынести в отдельный файл-скрипт.
6. Неверно понято расписание
Порядок пяти полей: минута, час, день месяца, месяц, день недели. Запись * 3 * * * означает не «раз в день в 3 часа», а «каждую минуту с 3:00 до 3:59». Правильный вариант — 0 3 * * *. Кроме того, часовой пояс сервера может не совпадать с ташкентским временем: проверьте его командой date и скорректируйте расписание.
7. Задание накладывается само на себя
Если скрипт работает 10 минут, а запускается каждые 5, одновременно начинают работать несколько копий. В итоге одно уведомление уходит дважды или в базе появляются ошибки блокировок. Утилита flock не даст запустить новую копию, пока не завершится предыдущая:
*/5 * * * * /usr/bin/flock -n /tmp/sms.lock /usr/bin/php /var/www/user/data/www/misol.uz/cron/sms.php >> /var/www/user/data/logs/sms.log 2>&18. Лимиты памяти и времени
Большой экспорт или скрипт резервного копирования может упереться в лимиты памяти или процессора тарифа и остановиться на середине. Если в логе видно «Allowed memory size exhausted» или «Killed», разбейте работу на части: например, обрабатывайте по 500 записей за один запуск. Тяжёлые задания также стоит планировать на ночь, когда нагрузка на сайт минимальна.
Пример: интернет-магазин в Ташкенте
Небольшой магазин бытовой техники написал скрипт, который каждую ночь в 2 часа пересчитывает цены по курсу доллара. Неделю цены не менялись, хотя в панели задание числилось активным. После добавления перенаправления в лог появилась строка «Failed opening required 'config.php'» — скрипт искал настройки по относительному пути. Добавили cd в начало команды, и на следующую ночь скрипт запустился, но выдал «syntax error»: cron вызывал старый PHP. После указания полного пути задание заработало. Обе ошибки нашли за 10 минут — исключительно благодаря логу.
Как проверить скрипт в условиях cron
Прежде чем ставить задание в расписание, проверьте его в окружении, близком к cron. Следующая команда запускает скрипт почти с пустым окружением и сразу показывает проблемы, связанные с PATH или переменными:
env -i /bin/sh -c 'cd /var/www/user/data/www/misol.uz && /usr/bin/php cron/kurs.php'На хостинге sayt.uz задания cron добавляются в разделе «Планировщик» панели ISPmanager, в которую вы входите из кабинета sayt.uz. Если лог остаётся пустым и задание, похоже, вообще не запускается, напишите тикет в техподдержку и приложите строку команды — системный лог cron можно проверить со стороны сервера.