Почему не работает Crontab в CentOS 7?

Question

[nak-alexey]

Здравствуйте! В CentOS из под root вызываю crontab -e создаю новую задачу. Лог файл показывает что задача была выполнена но по факту скрипт не запустился. Когда же вношу изменения в /etc/crontab и перезапуска сервис service crond restart задание успешно отрабатывает. Что это? Я проклят?

Comments

[Виктор Таран]

команду в студию лог в студию

[nak-alexey]

Виктор Таран,

Jan 10 18:56:01 localhost CROND[10242]: (root) CMD (root python3.6 /home/admin/Telegram_bot/main.py)

эту строку написал cron который был настроен через crontab -e. Если просто запустить эту команду в терминале то успешно все отработает.

[AVKor]

root предназначен для администрирования системы, а не для запуска ботов для телеграммки.

[hint000]

вместо python3.6 напишите полный путь /usr/bin/python3.6 (или где он у вас находится)

[nak-alexey]

AVKor, Только создал и пробую внедрять. Однозначно переделаю )

[nak-alexey]

hint000, Не чего не изменилось. К тому же в переменных crontab указаны и оболочка и пути.

[Вячеслав Рахинский]

Если строка с таской в кроне не имеет в конце символа перевода строки то задача в крон не будет выполнятся
Есть такой мелкий баг или фича, возможно ваш вариант

Answer 1

[Виктор Таран]

which python3.6
И вставить получившийся полный путь
КРОН НЕ имеет по умолчанию ПЕРЕМЕННУЮ PATH как следствие он не в состояние сам определить где лежит бинарник

Comments

[CityCat4]

О да! На эти грабли наступаешь постоянно. В некоторых кронтабах PATH выставляется, но все равно привыкаешь писать в скрипте полный путь или же детектить, где лежит бинарник.

Answer 2

[Andrey Koncedalov]

Лог файл показывает что задача была выполнена но по факту скрипт не запустился

Если в логе указанна что задача запустилась, значит запустился.
Вопрос в другом - как вы определяете, что не запустилось ?:
- процесс может в консоль выдавать ошибку или по таймеру ждать ввода и завершиться.

Для уверенности:
1) В начале скрипта запишите что-то в какой-то файл
2) В конце скрипта в этот же файл запишите что выполнено
3) И не пренебрегайте выводом логов при добалении в крон
/home/admin/Telegram_bot/main.py >> /home/admin/Telegram_bot/main.log 2>&1

И да, у пайтона есть свой шедуллер - python-crontab

Частая проблема - Глобальные переменные залогиненых пользователей и пользователя запускаемого по крону могут отличаться (как их наличие так и параметры) - тут нужно смотреть вашу систему.

Укажите в теме строчку из crontab -e и /etc/crontab - я не могу с этого поста зайти к вам в систему и увдеть, а не опечатались ли вы... По конкретике можно, что-то сказать.

Answer 3

[CityCat4]

А простите, с чего Вы решили, что crontab -e правит /etc/crontab? Команда сия правит рутовый персональный кронтаб, который лежит где-то в дебрях /var (где, искать ломы, но возможно /var/cron/tabs или что-то около этого)
А раз не запустился, значит с его кронтабом что-то не то.
Я не раз на такое натыкался, поэтому просто забил на crontab -e и просто правлю /etc/crontab при необходимости.

Comments

[Alexey Dmitriev]

/var/spool/cron/root

[Valdemar Smörman]

Alexey Dmitriev, этот файл создается, если вводится через sudo, если в системе есть Пользователь и работа ведётся в его профиле:
sudo crontab -e
А если в среде Пользователя ввести в Терминале:
crontab -e
то создаётся файл:
/var/spool/cron/имя_пользователя_в_системе

[Alexey Dmitriev]

Valdemar Smörman, прочитайте внимательно задачу - там указано, что идет работа из под рута.

[Valdemar Smörman]

Alexey Dmitriev, а, да, пропустил...

Допускаю, что скрипт может не иметь атрибута Исполняемый или неправильно сама команда на исполнение скрипта написана.
Других причин не работать не вижу...

Answer 4

[Евгений]

Используй systemd. Недавно на Хабре встречал интересную статью - использование таймеров systemd вместо заданий cron

Answer 5

[Valdemar Smörman]

Если в системе есть Пользователь и вы работаете в его среде, то при вводе в Терминал:
crontab -e
задание пишется в файл:
/var/spool/cron/имя_пользователя_в_системе
работать не будет.

Надо:
sudo crontab -e
и тогда уже задание пишется в файл:
/var/spool/cron/root
и так вот будет работать.
И обязательно апосля выполнить:
sudo /etc/init.d/cron restart

Можно в Терминале сразу, без открытия редактора и ручного ввода внести задание двумя способами:
1. Если задание ни разу вообще не добавлялось в системе в crontab, например:

echo -e '0 */8 * * * php /opt/acelist/as.php /opt/lists/as' | sudo crontab -

и в этом случае перезагружать cron не надо.

Но помните!!!
Добавить новое задание к существующему таким способом не получится, т.к. файл просто перезаписывается именно записанным в коде и оно - задание всегда будет единственным.

2. Если задание уже добавлялось в системе в crontab, то добавить новое можно так, например:

sudo sh -c "echo '0 */8 * * * php /opt/acelist/as.php /opt/lists/as' >> /var/spool/cron/crontabs/root"; sudo /etc/init.d/cron restart

в этом случае задание добавляется новой строкой в файл и уже перегрузка cron нужна, что в коде и присутствует.

Этот же, второй способ добавляет новой строкой и новое задание, если применялся Способ №1.

Answer 6

[Fenrir89]

Какая версия ядра?, какая версия selinux?, спрашиваю потому что в нескольких версиях ядер был глюк с блокировкой доступа к crontab из-за selinux причём не только к рутовому но и для других пользователей, попробуй его временно отключить, если поможет подбирай ядро на котором этот глюк исправлен