Захват вывода · MAILTO · чек-лист проверки логов
При сбое cron обычно молча проходит дальше. Если по этому инструменту выражение корректно, но задача всё равно не выполняется, проблема, скорее всего, не в выражении, а в среде выполнения. Разберём по порядку, как сузить круг причин.
Сохраняйте вывод в файл. cron по умолчанию отправляет стандартный вывод и стандартный поток ошибок задачи по почте, но если почта не настроена, они просто теряются. Если добавить после команды >> /var/log/myjob.log 2>&1, то и stdout, и stderr попадут в лог-файл, и вы сразу увидите, что произошло.
Получайте уведомления через MAILTO. Если поставить в начале crontab MAILTO="you@example.com", вывод и ошибки задачи будут приходить на этот адрес. Это самый простой предохранитель от тихих сбоев. И наоборот, если почта не нужна, оставьте пусто: MAILTO="".
Смотрите системные логи. В системах на базе Debian/Ubuntu используйте grep CRON /var/log/syslog, а в окружении systemd — journalctl -u cron (или crond), чтобы проверить, запустил ли cron задачу. Важно различать: «попытка выполнения» и «успех скрипта» — это разные вещи.
Наконец, чек-лист частых причин. ① Указаны ли все команды и файлы абсолютными путями? ② Объявлен ли нужный PATH в crontab? ③ Есть ли у скрипта право на выполнение (chmod +x)? ④ Добавлена ли задача в crontab нужного пользователя (crontab root и обычного пользователя — это разные вещи)? Проверьте эти четыре пункта, а само выражение ещё раз сверьте в этом расшифровщике.