Щоденна робота з крон не працює


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

Ідеї?


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 файли з щоденного крона, повинен бути соромним!
Сільвейн

Повинно бути публічно розпущеним! ;-) Цікаво, скільки часу люди колективно втратили через це рішення ... Мені теж цікаво, чи не було для цього вагомих причин?
xastor

3

Це може бути одна з кількох речей:

Корінь шлях:

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

PATH = / usr / sbin: / usr / bin: / sbin: / bin

src: 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, встановіть його самостійно в сценарії. Дивіться причини, чому кронтаб не працює
geirha

Корисне посилання, дякую. Дана причина не використовувати повний шлях - це портативність. Справедливо. Ще одне розумне рішення - визначити команди, які ви використовуєте на початку сценарію, разом з іншими конфігураціями: LS = / bin / ls; SRC_DIR = / home / joe / src. Потім використовуйте $ LS $ SRC_DIR. Зберігає все, що визначено вгорі та в одному місці.
Шон

Я вважаю, що для зменшення читабельності вам доведеться переходити кожну команду COMMAND = / path / to / command для кожної нової системи, на якій вона повинна працювати. В одній системі всі потрібні вам команди можуть бути в / usr / bin, на іншій - у / bin, інші в / usr / bin. Просто наявність обох / usr / bin та / bin в PATH робить це не проблемою. З іншого боку, імена змінних мають бути малими літерами, інакше ви ризикуєте змінити спеціальні змінні оболонки або змінні середовища.
geirha

re: імена змінних верхнього регістру. Я завжди робив це без особливих роздумів, завдяки першим сценаріям, які я бачив це робити. Але ви маєте рацію, немає перевернутого боку і шансів на зворотній бік. Дякуємо, що вказали на це, порушуючи цю звичку зараз.
Шон

1

Отримайте системний журнал для таких повідомлень;

crond: (*system*) BAD FILE MODE

файли повинні бути обмежені (достатньо) на 644):

chmod 0644 /etc/cron.d/my_crontab
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.