Почему крон для задач не работает

Я настроил cronjob для пользователя root в среде ubuntu следующим образом, набрав crontab –e:

  34 11 * * * sh /srv/www/live/CronJobs/daily.sh

  0 08 * * 2 sh /srv/www/live/CronJobs/weekly.sh

  0 08 1 * * sh /srv/www/live/CronJobs/monthly.sh

 Но cronjob не запускается. Я попробовал проверить, запущен ли cronjob с помощью pgrep cron, и результат был таким: идентификатор процесса 3033. Сценарий оболочки вызывает файл python и используется для отправки электронной почты. Запуск файла python проходит нормально. В нем нет ошибок, но cron не запускается. Файл daily.sh содержит следующий код:

python /srv/www/live/CronJobs/daily.py

python /srv/www/live/CronJobs/notification_email.py

python /srv/www/live/CronJobs/log_kpi.py

В чем моя проблема?

Ответ 1

Вот руководство по отладке некорректных cronjobs:

1. Запущен ли демон Cron?

2. Запустите ps ax|grep cron и поищите cron.

3. Debian: service cron start или service cron restart.

4. Работает ли cron?

* * * * * /bin/echo "cron работает" >> /tmp/file

5. Очевидно, что вам необходимо иметь доступ на запись к файлу, в который вы перенаправляете вывод. Уникальное имя файла в /tmp, не существующее в данный момент, всегда должно быть доступно для записи.

6. Возможно также добавить 2>&1 для включения стандартной ошибки в стандартный вывод или отдельно вывести ошибку в другой файл с помощью 2>>/tmp/errors.

7. Работает ли команда автономно?

8. Проверьте, нет ли в скрипте ошибки, выполнив пробный запуск через CLI.

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

10. Может ли cron выполнить ваше задание?

11. Проверьте /var/log/cron.log или /var/log/messages на наличие ошибок.

12. Установите флаг исполняемости для команды: chmod +x /var/www/app/cron/do-stuff.php.

13. Если вы перенаправляете вывод команды в файл, убедитесь, что у вас есть разрешение на запись в этот файл/каталог.

14. Проверьте строку she-bangs / hashbangs.

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

16. Не подавляйте вывод при отладке.

17. Обычно используется следующее подавление: 30 1 * * * command > /dev/null 2>&1.

18. Заново включите стандартный вывод или стандартный вывод сообщений об ошибках, удалив >/dev/null 2>&1 вообще; или, возможно, перенаправьте в файл в том месте, где у вас есть доступ на запись: >>cron.out 2>&1 добавит стандартный вывод и стандартную ошибку в файл cron.out в домашнем каталоге вызывающего пользователя.

Ответ 2

Еще одна причина отказа crontab: специальная обработка символа %.

Из файла руководства:

Вся командная часть строки, вплоть до новой строки или символа

«%», будет выполнена командой /bin/sh или оболочкой, указанной

в переменной SHELL cronfile.  Символ «%» в

в команде, если он не экранирован обратной косой чертой (\), будет заменен на

символы новой строки, и все данные после первого % будут отправлены в

команду как стандартный ввод.

В моем случае я использовал date --date="7 дней назад" "+%Y-%m-%d" для создания параметров моего скрипта, и он выдавал ошибку.

Ответ 3

Для меня решение заключалось в том, что файл, который пытался запустить cron, находился в зашифрованном каталоге, точнее, в пользовательском каталоге /home/. Хотя crontab был настроен как root, поскольку запускаемый скрипт находился в зашифрованном каталоге пользователя в /home/, cron мог читать этот каталог только тогда, когда пользователь был действительно залогинен. Чтобы узнать, зашифрован ли каталог, проверьте, существует ли этот каталог:

/home/.ecryptfs/<yourusername>

Если это так, то у вас есть зашифрованный домашний каталог.

Ответ 4

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

 Распространенным симптомом является получение сообщений об ошибке DISPLAY или о том, что процесс задания cron не может получить доступ к отображению на мониторе. Вкратце это означает, что программа, которую вы пытаетесь запустить, пытается отобразить что-то на дисплее X11 (или Wayland и т. д.), и ничего не получается, потому что cron не подключен к графической среде или вообще к каким-либо средствам ввода/вывода, кроме возможности чтения и записи файлов и отправки электронной почты, если система настроена на это. Для целей «Я не могу запустить задание cron» давайте просто укажем в общих чертах три распространенных сценария этой проблемы. Если вы пытаетесь запустить интерактивную программу, которая общается с пользователем, вам стоит переосмыслить свой подход. Распространенным, но нетривиальным решением является разделение программы на две части: внутренний сервис, который может запускаться из cron, но не имеет никаких видимых пользователю интерактивных средств, и внешний клиент, который пользователь запускает из своего графического интерфейса, когда хочет общаться с внутренним сервисом.

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

2. Я полагаю, что внутренняя служба может быть запущена из cron, но, если она требует GUI, возможно, запустив ее из сценариев запуска сервера X11, используя etc/rc.local или подобный каталог запуска системы более традиционно, вы добьетесь успеха.

3. Если вы пытаетесь запустить программу с графическим интерфейсом без взаимодействия с реальным пользователем, вы можете установить «безхидерный» сервер X11 3 и, запустив задание cron, которое запускает этот сервер, выполните ваше задание и завершите работу.

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

Вероятно, ваши сценарии запуска должны просто запускать графический интерфейс (X11 или какой-либо другой) и подключаться к его сценарию запуска, чтобы также запустить клиентскую программу, когда графический интерфейс будет запущен. Другими словами, вам не нужен cron; просто настройте сценарии запуска на запуск графического интерфейса рабочего стола и настройте графический интерфейс рабочего стола на запуск вашего приложения как последовательности входа в систему.

Существуют способы запуска программ X11 на основном дисплее системы (DISPLAY=:0.0), но сделать это из задания cron часто проблематично, поскольку этот дисплей обычно зарезервирован для фактического интерактивного использования первым пользователем, который входит в систему и запускает графический рабочий стол. Дополнительная сложность заключается в том, чтобы решить, от имени какого пользователя запускать задание cron. Общие системные ресурсы, такие как внутренние службы, могут и, вероятно, должны запускаться от имени root (хотя в идеале они должны иметь выделенную системную учетную запись, под которой они переключаются после получения доступа к любым необходимым им привилегированным ресурсам), но все, что связано с графическим интерфейсом, определенно не должно запускаться от имени root ни в коем случае.

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