Чому мій кронтаб не спрацьовував?

Я crontab -eдодавав наступний рядок до мого crontab:

* * * * * echo hi >> /home/myusername/test

Але я не бачу, щоб тестовий файл записаний. Це проблема з дозволом чи crontab не працює належним чином?

Я бачу, що процес кронів працює. Як я можу це налагодити?

Редагувати - Задайте питання Ubuntu про хороше запитання щодо crontab , на жаль, що досі мені не допомагає.

Редагувати 2 - Гм, здається, у моєму тестовому файлі є 214 рядків, це означає, що за останні 214 хвилин він писався щохвилини. Я не впевнений, у чому була проблема, але явно її немає.

Є реалізація cron(не всі вони, і я не пам’ятаю, який вільний, але я стикався з одним під Linux), які перевіряють наявність оновлених файлів crontab щохвилини на хвилину і не розглядають нові записи до наступної хвилини . Тому вперше вогонь може зайняти до двох хвилин. Це може бути те, що ви спостерігали.

Ви додали порожній рядок після своєї роботи ?

У мене була така ж проблема - робочий кронтаб несподівано зупинився після того, як я додав новий запис наприкінці. Виявилося, що я забув поставити нову лінію після цього останнього рядка.

Я це з’ясував, видавши команду

cat /var/log/syslog | grep crontab

і вихід показав проблему:

Jul  2 08:16:01 shiva cron[1254]: (*system*) RELOAD (/etc/crontab)
Jul  2 08:16:01 shiva cron[1254]: (*system*) ERROR (Missing newline before EOF, this crontab file will be ignored)

Додавання нового рядка та збереження вирішили проблему.

Схоже, це фіксовано. Наступного разу спробуйте також записати STDERR. Наступне буде входити в STDOUT, а не STDERR:

* * * * * echo hi >> /home/myusername/test

Постарайтеся переконатися, що також існує явний пункт щодо STDERR. В іншому випадку STDERR може бути надісланий користувачеві електронною поштою (якщо припустити, що електронна пошта працює) або взагалі нікуди не подітись, залежно від налаштування Cron.

* * * * * echo hi >> /home/myusername/test 2> /home/myusername/test.stderr

Моя перевага - надсилати cronjob вихід у syslog. Таким чином я використовую будь-яку існуючу інфраструктуру системного журналу (централізовані системи, Splunk, обертання журналу вже підтримується, легко порівнювати повідомлення в / var / log / messages & / var / log / cronjob тощо), і я не спам сисадмінів (мене) із непотрібними електронними листами.

* * * * * echo hi >> /home/myusername/test 2>&1 | /usr/bin/logger -t mycronjob

У мене проблема полягала в тому, що сценарій не був виконаним. У мене була така настройка crontab -e

* * * * * /bin/my-script.sh

І файловий скрипт не виконувався, тому я побіг

chmod +x my-script.sh

Відразу я почав бачити вихід, як очікувалося.

Ваша лінія cron працює чудово на моєму комп’ютері, коли я переходжу myusernaeна phunehehe. Існує кілька способів з’ясувати, що не так у вашій системі.

Cron зазвичай надсилає пошту користувачеві, коли щось не так. Якщо ви бачите повідомлення "У вас є пошта", скористайтеся поштовим клієнтом, щоб перевірити вашу поштову скриньку . Або перевірте у своєму домашньому каталозі, чи там може бути названий файл dead.letter.

Ви можете перевірити /var/log/записи, що стосуються cron. На моєму комп'ютері файл журналу знаходиться за адресою /var/log/cron/current(вимагає кореневого доступу).

Якщо у вас є кореневий доступ, ви можете зупинити демон cron і запустити його в режимі налагодження. Наприклад, я б використав (змінити fcronім'я вашого демона):

killall fcron
fcron --foreground --debug

Швидше за все, коли cron виходить з ладу, він генерує електронну пошту до ідентифікатора користувача роботи cron на цьому комп’ютері. Якщо у вас на комп'ютері не працює MTA, або ви не читаєте чи не пересилаєте цю пошту кудись інше, ви не побачите це повідомлення, навіть якщо MTA працює.

Хороший спосіб отримати помилки вашого Crontab поштою - зробити так, щоб ваш crontab виглядав так:

MAILTO="myemail@example.com"
* * * * * echo hi >> /home/myusernae/test

Очевидно, використовуйте свою електронну адресу, а не myemail@example.com. Це повідомляє cron надсилати помилки на вашу електронну адресу, а не на локальний рахунок. Зокрема, це корисно, якщо у вас є кореневий crontab (або фрагмент crontab в /etc/cron.d), який ви хочете просто надіслати до вас, ви можете уникнути поштової скриньки кореневої пошти або кореневої адреси кореневої пошти.

Я б припустив, що однією з причин цього може бути те, що / home / каталог зашифровано, і коли користувач вийшов із системи, cron не може зробити нічого в цьому каталозі.

дивіться: /programming//a/40354269/1279002