Ежедневная работа cron не выполняется

10

Краткий обзор: у меня есть скрипт, который будет ежедневно делать резервные копии моего хранилища исходного кода из SVN в архив на этот день. Я протестировал скрипт, и он работает очень хорошо, пока я запускаю его как sudo, из-за владения выходным каталогом.

Итак, проблема в том, что я хочу запускать это ежедневно, поэтому я помещаю ссылку на него в каталог /etc/cron.daily. Вот содержимое каталога.

thom@spenser:/etc/cron.daily$ ls -l
total 60
-rwxr-xr-x 1 root root   189 2011-09-14 02:21 apport
-rwxr-xr-x 1 root root 15535 2011-10-06 11:30 apt
-rwxr-xr-x 1 root root   314 2011-08-08 16:57 aptitude
lrwxrwxrwx 1 root root    24 2012-02-28 11:05 backup -> /usr/local/bin/backup.sh
-rwxr-xr-x 1 root root   502 2011-06-08 11:48 bsdmainutils
-rwxr-xr-x 1 root root   256 2011-10-06 04:04 dpkg
-rwxr-xr-x 1 root root   372 2011-10-04 16:50 logrotate
-rwxr-xr-x 1 root root  1353 2011-07-27 07:17 man-db
-rwxr-xr-x 1 root root   606 2011-08-17 09:16 mlocate
-rwxr-xr-x 1 root root   249 2011-06-24 05:36 passwd
-rwxr-xr-x 1 root root  2417 2011-07-01 17:25 popularity-contest
-rwxr-xr-x 1 root root   383 2011-09-30 15:09 samba
-rwxr-xr-x 1 root root  3594 2011-09-19 20:07 standard
thom@spenser:/etc/cron.daily$ 

Проблема в том, что он просто никогда не запускается. Вот разрешения для этого скрипта:

thom@spenser:/etc/cron.daily$ ls -l /usr/local/bin/backup.sh 
-rwxr-xr-x 1 root root 260 2012-02-28 11:03 /usr/local/bin/backup.sh

Идеи?

Thom
источник
2
Если возможно, подумайте над тем, чтобы закрыть некоторые другие открытые вопросы, выбрав лучший ответ (если он есть). Нам нужно, чтобы пользователи поддерживали свои вопросы, чтобы сайт мог стать эффективным инструментом для следующего человека с вашими проблемами. Для получения более подробной информации о передовом опыте рассмотрите вопрос с ответами на часто задаваемые вопросы .
Бруно Перейра

Ответы:

37

Пробовал это

run-parts --test /etc/cron.daily

Обнаружил, что мой файл update.ubuntu не подошел. Также заметил, что мой файл имеет расширение (имеет точку в нем).

Шаги, чтобы это исправить.

  1. Переименовал мой update.ubuntu в update-ubuntu
  2. Теперь снова run-parts --test /etc/cron.daily, на этот раз мой файл вышел!
Д Дурга Прасад
источник
1
Да, это исправило это для меня. Ему не нравятся точки в имени файла, переименование моего файла из myscript.sh в myscript работает для меня.
Мэтт Паркинс
3
Это должно быть выше. Мой сценарий был сохранен как традиционный «backup.sh». Удаление части ".sh" решило это. Благодаря тонну!
Дэвид
Спасибо! Парня / Гал, который решил неявно удалять .sh файлы из ежедневного cron, должно быть стыдно!
Сильвен
Должны быть публично пороли! ;-) Интересно, сколько времени люди коллективно потеряли из-за этого решения ... Мне также интересно, была ли для этого веская причина?
xastor
3

Может быть одна из нескольких вещей:

Корни пути:

В зависимости от выполняемых команд вам может потребоваться расширить переменную PATH корневого пользователя, поместив следующую строку в верхней части их файла crontab:

PATH = / USR / SBIN: / USR / бен: / SBIN: / бен

источник: https://help.ubuntu.com/community/CronHowto

Или просто используйте полные пути к каждой команде в вашем скрипте: /bin/lsвместо, lsнапример. ( which lsв командной строке для путей).

В названии файла есть странная ошибка с точками . Может распространиться на файл, на который вы ссылаетесь, хотя это кажется маловероятным.

Вы сохраняете вывод из файла резервной копии? Поместите что-то вроде этого в первую строку, чтобы определить, запущено ли оно вообще или работает, но в какой-то момент происходит сбой.

/bin/echo "Attempting to run backup" >> /path-to-home/backup.log

Или попробуйте добавить скрипт в файл crontab напрямую:

sudo -i
crontab -e
[add the next line to the file, then save and exit]
33 15 * * * /usr/local/bin/backup.sh

будет работать в 15:30 каждый день, если машина включена. используйте * * * * * во время тестирования, чтобы запускаться раз в минуту до тех пор, пока он не заработает.

Шон
источник
1
Использование абсолютных путей в сценариях не рекомендуется. Если вы не знаете, что такое PATH, задайте его самостоятельно в сценарии. Посмотрите причины, по которым crontab не работает
гейра
Полезная ссылка, спасибо. Данная причина не использовать полные пути - это переносимость. Справедливо. Другое разумное решение - определить команды, которые вы используете в начале скрипта, вместе с другими конфигурациями: LS = / bin / ls; SRC_DIR = / дом / джо / ЦСИ. Затем используйте $ LS $ SRC_DIR. Хранит все определенное сверху и в одном месте.
Шон
Я нахожу это для уменьшения читабельности, и вы должны просмотреть каждую команду COMMAND = / path / to / для каждой новой системы, на которой она должна работать. В одной системе все необходимые вам команды могут находиться в / usr / bin, в другой - в / bin, другие - в / usr / bin. Если в PATH есть и / usr / bin, и / bin, это не проблема. Напомним, что имена переменных должны быть строчными, иначе вы рискуете переопределить специальные переменные оболочки или переменные окружения.
гейра
re: имена переменных верхнего регистра. Я всегда делал это без долгих раздумий, потому что первые сценарии, которые я видел, делали это. Но вы правы, нет никаких преимуществ и шансов на снижение. Спасибо за указание на это, избавление от этой привычки сейчас.
Шон
1

Grep ваш системный журнал для сообщений, как;

crond: (*system*) BAD FILE MODE

файлы должны быть ограничены (достаточно) на 644):

chmod 0644 /etc/cron.d/my_crontab
Том Х
источник