have again a smaller problem. To anticipate it, due to many problems in the update to Turris OS 3.5 I have made a fresh installation with the medkit. Currently it is now 3.5.1!
It runs now everything, only cron I get not to run. It is simply not executed, when sending in LUCI nothing happens.
Is it a rights issue? Cron in system start is activated!
My line looks as follows:
Reboot router every sunday at 06:00 am -> with # in front, the formatting writes otherwise bold
59 5 * * 0 sleep 70 && /sbin/reboot
I am getting this (if i try to enable root crontab with default fan_control script) info /usr/sbin/cron[5649]: (root) BAD FILE MODE (crontabs/root)
… meanwhile all in cron.d is working perfectly, for example info /usr/sbin/cron[23050]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
I remember i have lot of troubles to make my/etc/cron.d/rainbow_control working. (tab vs space, blank eol before eof, wrong eol … ). In the end i used some working corntabfile and edit it carefully until i make it working (i never seen such sensitive cron … usually space/tab does not matter and on deb/ubuntu any blanks are not parsed … on TO …damned, just one space on wrong place and cron screams
So i am pretty sure you just have somehow wrongly formatted your crontab file, that's it.
EDIT: 59 5 * * 0 sleep 70 && touch /etc/banner && reboot # you have to do something (touch a file for example) to start the timer more info is here : https://wiki.openwrt.org/doc/howto/cron
Files in /etc/cron.d/ must have also specific “user” before command. 59 5 * * 0 root sleep 70 && /sbin/reboot
Also don’t forget: last line in this files must be blank.
What surprised me the most is the fact that up to version 3.4 of the Turris OS there were no problems. This command itself worked:
0 6 * * 0 reboot
Since I was registered with root, he also applied it.
Now I have changed from Maxmilian’s post the example on me.
Sending has still no effect.
Can it be that another required service is not active or is not installed?
Property this time during the installation in the updater left a lot which I do not need to keep it slim.
Funfact: Du kannst deine Posts editieren, muss kein Doppelpost sein
Did you try to the command in a script file and run this? For example /root/reboot.sh (don’t forget to make it executable) and run this from the cron. Maybe there is a glitch with the ampersand.
Problem is that any command might work on shell, but in cron you have to specify full path because cron does not know about your full $PATH and rest of the environment setup.
I found the mistake! I set the command line above and the description with “#” below in a new line. After that it worked.
I always thought lines with “#” would be ignored.
As has been said, cron is very sensitive.
Jah we got it to work, simply by using: crontab -e. It is the DO NOT EDIT THIS FILE - edit the master and reinstall. instruction that is confusing us (a bit) though.
/etc/cron.d/ here you have crontabs which are doing specific tasks (logrotation, led intensity control, and so on) , it is more likely dedicated to some services/packages/applications…
/etc/crontabs here you have ‘root’ file which is system crontab file , any other user specific crontab will be there as well with name of that user.
/var/spool/cron/crontabs this is real spool location (usually crontabs is symlink to /etc/crontabs )
Basically user crontabs must be edited using crontab -u <username> -e and when correctly saved/parsed = means it is installed. System crontab can be edited same waycrontab -e (when in shell as root) or crontab -u root -e and additionally you can use LUCI. On the other hand /etc/cron.d/ files can be edited directly in shell (can’t be done via LUCI).
So for example if i want to control led intensity i just create /etc/cron.d/rainbow_intensity file , put my ‘cron’ entries there like used to. This is not validated after save (you have to check log if that cron.d was parsed correctly and actually executed).
If i want to have/add some own admin tasks , crontab -u root -e and put what i need there. This is validated after save (if something is wrong it is not installed and you can re-edit or return to previous working one). To create some user crontab … simply crontab -u <username> -e . If something is not right, crontab refuse to install it.
if different or not right try crontab -u root -e and you should be in “vi” editor, delete/edit/add what you need after saving you should see something like:
Screen:/etc/crontabs# crontab -u root -e
crontab: installing new crontab
as last issue command “sync” and wait one minute and check system log, and recheck content of that file again.
some background: Crontab can live with wrong crontab files(and their content),he just ignore it, that comment block is self-defense mechanism of Sir Mighty Cron when users are editing his files directly, he recognize that own comment and post message to log (… aside /etc/cron.d/ files are isolated from users, so some other scheduled tasks are normally dispatched … and you will see some regular messages from cron service).
Yah, I figured as much (I feel that a file-wrapper in LuCI could help for newbies as the the warning will no longer be visible nor needed (as the file is not edited directly).
Thanks for confirming it is safe to use the LuCI editor (and thus ignore the warning) although I’m comfortable enough with CLI and crontab -e too (as I use that on all my Linux machines).
