Як дізнатись, чому cron не працює на моїх роботах?

15

Я використовую Ubuntu 14.04, і демон cron працює:

# ps ax | grep cron
822 ?        Ss     0:00 cron

але це не виконує жодної роботи. Раніше я отримував /var/log/syslogтакі записи :

2014-05-04T11:47:01.839754+01:00 localhost CRON[29253]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ))

але зараз немає записів, пов'язаних з кроном. Я також отримував такі записи в /var/log/auth.log:

2014-05-04T11:47:01.839183+01:00 localhost CRON[29252]: pam_unix(cron:session): session opened for user root by (uid=0)
2014-05-04T11:47:13.495691+01:00 localhost CRON[29252]: pam_unix(cron:session): session closed for user root

але знову ж таки, зараз немає записів, пов'язаних з кроном.

Я не знаю, що щось змінилося. Я спробував перезапустити cron:

# service cron restart
cron stop/waiting
cron start/running, process 24907

Я спробував crontab -eдодати роботу cron, * * * * * date >> /tmp/somefileяка працювала, але вона встановила новий crontab /var/spool/cron/crontabs/root, тоді як я хочу, щоб cron використовував файл у /etc/crontab.

Чи є якийсь варіант налагодження, який я можу використовувати, або журнал десь може подати повідомлення про помилку, яке я можу дослідити?

ubuntu cron

— jl6
джерело

1

Що відображається на crontab -l?

— user345352353

no crontab for root.

— jl6

Я вірю, що якщо ви просто трохи пошукаєте на цьому веб-сайті SE, ви отримаєте відповідь. Це досить поширена проблема.

— mdpc

Корони, отримані за допомогою crontabкоманди ( -lперемикача), залежать від користувача, тоді /etc/crontabяк використовуються для зберігання загальносистемних кронів. З цієї причини збережені в ній завдання /etc/crontabне з’являться ні в кого crontab -l.

— Джон У. Сміт

Зауважте, що у несправності сервера є канонічне запитання про налагодження в роботі cronjob, яке може допомогти.

— Уайлдкард

4

Щоб додатково допомогти вам налагодити те, що не так у ваших cronробочих місцях, слід перевірити свою пошту. Зазвичай це зберігається у файлі на зразок /var/mail/<user_name>або /var/spool/mail/<user_name>.

Ці два файли насправді є жорсткими посиланнями на моєму вікні Debian, але я не знаю, чи це стандарт.

Пояснення

Зі cron(8)сторінки:

Під час виконання команд будь-який вихід надсилається по електронній пошті власнику crontab (або користувачеві, названому в змінній середовища MAILTO в crontab, якщо такий існує).

— Джозеф Р.
джерело

Я перевірив пошту; не створюється жоден файл, а також не існує файлу dead.letter.

— jl6

0

Ви показали, що немає коронного крота для кореня, чи є у користувачів користувачі із записом crontab? Якщо ви використовуєте тільки root, ви також можете перевірити наступні каталоги: /etc/cron.daily/ - /etc/cron.hourly/ - /etc/cron.monthly/ - /etc/cron.weekly

на моїй машині (centos 6.4) у мене є mlocate.cron всередині каталогу /etc/cron.daily/ і cron виконує цей сценарій щодня.

тож я думаю, що вам просто потрібно додати завдання на Cron.

— Хадспет
джерело

Але є файл crontab у /etc/crontab. Можливо, питання полягає в тому, чому він crontab -lне визнає цього?

— jl6

0

Я вирішив це, змінивши дозволи на /etc/crontabтакі:

-rw-r--r-- 1 root root 778 May 10 21:31 /etc/crontab

Раніше це було -rw-rw-r--. Це була єдина зміна. Це не працювало, тепер це так. Досі не впевнений, чому.

— jl6
джерело

1

Корневий crontab буде виконувати будь-які команди як root. Дозволи, що дозволяють отримати доступ до запису до некореневих, вважатимуться захисним отвором.

— ChuckCottrill

@ChuckCottrill: Але біт запису для групи дав би доступ до запису лише тим, хто знаходиться в кореневій групі - імовірно, це лише користувачі root?

— jl6

0

У мене також був подібний тип проблеми, але після визначення корінця як користувача на /etc/crontab, робота cron почала спрацьовувати.

Це може бути пов’язано з синтаксисом, за crontab -eяким він відрізняється від /etc/crontab.

— MohanBabu
джерело