sudo Crontab не работает, но crontab? :)
Я использую Crontab для моего пользователя, чтобы запускать много скриптов curl, они работают нормально, 40 из них работают.
Но скрипты, которые у меня есть в корневом «Crontab», используя commando 'sudo crontab -e ', не работают, они прекратили работу около 1 месяца назад и отлично работали более двух лет.
Попытались поговорить с людьми сервера, и никто из них не знает, что может быть неправильно. BTW Я не эксперт на сервере, я могу следовать за гидом, но вот он :)
Я попытался: перезапустить службу cron, «установить новый crontab», запустить скрипты в обычном crontab, используя пользователь root, перезагрузив сервер, удалив все в файле, удалив MAILTO.
Все скрипты работают, просто запуская их вручную.
это прекрасный, который не работает:
MAILTO = ""
2 3 * * * "/usr/local/scripts/backup-mysql.sh"
25 3 * * * "/usr/local/scripts/backup-prestashop.sh"
2 ответа
Наиболее полезным должно быть получение сообщений об ошибках.
2 3 * * * { date; bash -v "/usr/local/scripts/backup-mysql.sh"; date; } &>/tmp/cron-backup-mysql.log
25 3 * * * { date; bash -v "/usr/local/scripts/backup-prestashop.sh"; date; } &>/tmp/cron-backup-prestashop.log
Выход записывается в /tmp/cron-backup-mysql.log и /tmp/cron-backup-prestashop.log. bash -v выводит строки сценария по мере их чтения.
Вы можете проверить владельца файла, чтобы он выполнялся с правами root. Затем прочитайте файл, у вас есть время начала и окончания, чтобы проверить, завершен ли запуск, и если продолжительность - это то, что вы ожидаете.
Если скрипт теперь работает правильно, проблема, вероятно, в том, что оболочка вызывалась неявно (удалить bash -v из crontab и добавить echo SHELL = $SHELL к скрипту) или разрешения на выполнение, отсутствующие в скрипте (chmod +x).
Если сбой сценария, bash -v поможет вам найти баг. Вы можете показать более подробную информацию, заменив -v на -x, но это будет заливать вывод каждым выражением по мере их оценки.
Наиболее полезным должно быть получение сообщений об ошибках.
2 3 * * * { date; bash -v "/usr/local/scripts/backup-mysql.sh"; date; } &>/tmp/cron-backup-mysql.log
25 3 * * * { date; bash -v "/usr/local/scripts/backup-prestashop.sh"; date; } &>/tmp/cron-backup-prestashop.log
Выход записывается в /tmp/cron-backup-mysql.log и /tmp/cron-backup-prestashop.log. bash -v выводит строки сценария по мере их чтения.
Вы можете проверить владельца файла, чтобы он выполнялся с правами root. Затем прочитайте файл, у вас есть время начала и окончания, чтобы проверить, завершен ли запуск, и если продолжительность - это то, что вы ожидаете.
Если скрипт теперь работает правильно, проблема, вероятно, в том, что оболочка вызывалась неявно (удалить bash -v из crontab и добавить echo SHELL = $SHELL к скрипту) или разрешения на выполнение, отсутствующие в скрипте (chmod +x).
Если сбой сценария, bash -v поможет вам найти баг. Вы можете показать более подробную информацию, заменив -v на -x, но это будет заливать вывод каждым выражением по мере их оценки.