Cron does not work?!

Hello together,

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 :slight_smile:
59 5 * * 0 sleep 70 && /sbin/reboot

Thank you in advance for your help and patience!

use the “preformatted text” ( < / > sign ) :wink:

indent preformatted text by 4 spaces
# Reboot router every sunday at 06:00 am


is the cron scheduler running?

# ps | grep cron | grep -v grep
 8027 root       752 S    /usr/sbin/cron -n

Where did you enter the cronjob? crontab -e? Or a file in /etc/cron.d/ ?

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/

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 :slight_smile: … 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 :slight_smile:

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 :slight_smile: more info is here :

Thanks for the tip :slight_smile:
Cron runs, is in the processes. However, 3x what surprised me.
Have the command written in the system crontab of Luci.

But what startles me most is, why do you sleep 70 and then do the command? Why not set the command to a later point in time? :wink:

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.

1 Like

I have done this because of:
(Is in German, my actual language).

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.

Or can it be a bug in the 3.5 version?

Funfact: Du kannst deine Posts editieren, muss kein Doppelpost sein :wink:

Did you try to the command in a script file and run this? For example /root/ (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.

Thank you for the support, great forum!

How did you manage to use Cron?

We keep running into an DO NOT EDIT THIS FILE - edit the master and reinstall. instruction if we use the LUCI interface: System > Scheduled Tasks: add a task to the file (empty at the start).

Could you help us figure that one out?

It needs little bit experimenting, but even in LuCI it does work.

What about crontab ?!? (on the console, of course)

root@turris:~# crontab --help
crontab: unrecognized option: -
crontab: usage error: unrecognized option
usage: crontab [-u user] file
crontab [-u user] [ -e | -l | -r ]
(default operation is replace, per 1003.2)
-e (edit user’s crontab)
-l (list user’s crontab)
-r (delete user’s crontab)

Don’t forget to write changes to be reinstalled :wink:

1 Like

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.

1 Like

Thanks all for the explanations! We got it to work now.

However the following message in LuCi keeps warning us (although everything functions as expected):

In luci simply remove that comment block. Hit Save & apply.

In shell check ownership and rights (and content) of /etc/crontabs/root file.
It should looks like:

Screen:/etc# ltr crontabs/
-rw------- 1 root root 0 May 22 18:28 root

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).

1 Like

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).