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

Вот мой 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. Время и дата верны. Есть идеи?

Источник

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 (некоторые программы зависят от этого)
  • так далее

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

Источник

Один очень сложный источник неработающей программы cron (Red Hat) - это когда вы используете: crontab -e

для редактирования cron-файла,

вы должны ВЫЙТИ, а не просто сохранить.

Таким образом:w, а затем оставаясь в файле, не вызовет изменений. вы должны использовать:wq (команда VIM)

Источник
Другие вопросы по тегам