Crontab не будет выполнять скрипт

Question

Вот мой cron:

crontab -l

30 2 * * * /usr/sbin/stime&
32 2 * * * /usr/sbin/rtc -s
30 2 2 * * /usr/sbin/rtc -c
00 5 * * * /path/to/script/backup.sh >/dev/null 2>&1

Вот мой сценарий:

backup.sh

#!/bin/sh

rsync -e"ssh -i /path.to/id_rsa" -aP MyUsername@HostIP:/path/to/host/backup/ /path/to/local/backup --exclude '*.sql'

Если я запускаю backup.sh из командной строки, он выполняется. Крон не будет управлять им.

Я подумал, что это может быть проблема с rghts, поэтому я изменил команду в crontab следующим образом:

00 5 * * * su - root -c /path/to/script/backup.sh >/dev/null 2>&1

Все еще нет казни от crontab. Время и дата верны. Есть идеи?

Answer 1

Не выбрасывайте потенциально полезные сообщения

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

Таким образом, запись cron будет

00 5 * * * /path/to/script/backup.sh >/tmp/backup.out 2>&1

Сделать скрипты самодокументирующими

Я также обычно проверяю что-то полезное, добавляя диагностический вывод в скрипт:

#!/bin/sh
echo "Backup starting..."
date
rsync -e"ssh -i /path.to/id_rsa" \
      -aP MyUsername@HostIP:/path/to/host/backup/ \ 
      /path/to/local/backup \
      --exclude '*.sql'    
echo "Backup ended"

Проверьте справочные страницы

Страница руководства для rsync говорит

-q, --quiet
This option decreases the amount of information you are given during the 
transfer, notably suppressing information messages from the remote server. 
This option is useful when invoking rsync from cron.

Таким образом, вполне вероятно, что когда вывод rsync направлен в /dev /null, rsync замечает, что STDOUT не подключен к терминалу или обычному файлу, и завершается с ошибкой.

Вы можете проверить это, изменив команду cron на

00 5 * * * /path/to/script/backup.sh >/dev/null 2>/tmp/backup.err

а затем просмотрите содержимое /tmp/backup.err

Однако добавление опции -q было бы подходящим решением.

Пакетная оболочка не похожа на интерактивную оболочку

Как правило, при запуске из cron есть некоторые существенные отличия от запуска в интерактивном режиме.

• Вы не можете полагаться на устанавливаемые переменные окружения (основная проблема)
• К процессу не привязан TTY (некоторые программы зависят от этого)
• так далее

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