Why doesn't Crontab work on CentOS 7?

Question

linux

Hello! On CentOS, I call as root and crontab -ecreate a new task. The log file shows that the task was completed, but in fact the script did not start. When I make changes to /etc/crontab and restart the service, service crond restartthe task successfully completes. What is it? Am I cursed?

Answer 1

which python3.6
And insert the resulting full
CRON path DOES NOT have a PATH VARIABLE by default, as a result, it is not able to determine where the binary is

Answer 2

The log file shows that the task was completed, but in fact the script did not start

If the log indicates that the task has started, then it has started.
The question is different - how do you determine what did not start?:
- the process can give an error to the console or wait for input on a timer and end.
To be sure:
1) At the beginning of the script, write something to a file
2) At the end of the script, write to the same file what is done
3) And do not neglect the output of logs when adding to
crons /home/admin/Telegram_bot/main.py >> /home/admin/Telegram_bot/main.log 2>&1
And yes, python has its own scheduler - python-crontab
Frequent problem - Global variables of logged in users and the user launched by cron can differ (both their presence and parameters) - here you need to look at your system.
Indicate a line from crontab -e and /etc/crontab in the subject line - I can’t log into your system from this post and see if you’ve mistyped ... On the specifics, you can say something.

Answer 3

Excuse me, why did you decide that crontab -e/etc/crontab rules? This command edits the root personal crontab, which lies somewhere in the wilds of /var (where to look for crowbars, but maybe /var/cron/tabs or something like that)
. then.
I came across this more than once, so I just scored on crontab -e and just edit /etc/crontab if necessary.

Answer 4

Use systemd. Recently I came across an interesting article on Habré - using systemd timers instead of cron jobs

Answer 5

If there is a User in the system and you work in his environment, then when you enter into the Terminal:
crontab -e
the task is written to a file:
/var/spool/cron/имя_пользователя_в_системе
it will not work.
It is necessary:
sudo crontab -e
​​and then the task is already written to the file:
/var/spool/cron/root
and so it will work.
And be sure to do it afterwards:
sudo /etc/init.d/cron restart
You can immediately add a task in the Terminal, without opening the editor and manual input, in two ways:
1. If the task has never been added to the system in crontab at all, for example:

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

and in this case there is no need to reload cron.
But remember!!!
Adding a new task to an existing one in this way will not work, because the file is simply overwritten exactly as written in the code, and it - the task will always be the only one.
2. If the task has already been added to the system in crontab, then you can add a new one like this, for example:

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

in this case, the task is added as a new line to the file and a cron overload is already needed, which is present in the code.
The same, second method adds a new line and a new task, if Method No. 1 was used.

Answer 6

What kernel version?, what version of selinux? this glitch has been fixed