cronjobs not working!

[kavastudios]

Hi!

I have some task scheduled to be executed by the cronjobs

here's one example of my tasks

*/2 * * * * /www/res.sh

5 * * * * php-cgi /www/up.php > /dev/null 2>&1

59 23 * * * reboot -f

and the tasks are never executed.

I don't know if it's the way I wrote the tasks or how do I enable the cronjobs? (in the admin panel shows the cron as enabled)

thanks

[fringes]

I would SSH in (as root of course) and verify it was properly saved with "crontab -l". I don't know if it's necessary, but put a new-line after the last command before saving. Remember that cron commands may not have the same shell environment you expect, so try something like the following:

* * * * * /usr/bin/env > /tmp/env 2>&1

After one minute, check the contents of /tmp/env.

Most importantly, redirect stdout & stderr to a file (other than /dev/null) for all the commands, especially shell scripts, at least until you have it all working.

EDIT: Also, I probably wouldn't use the -f on the reboot if you are trying to preserve open files.

Edited May 5, 2015 by fringes

[s1tl]

For the sh script can you make sure that it is executable?

Also you may need to set the shell to use

*/2 * * * * bash /www/script.sh

Finally maybe add some loggintng in there?

logger "starting script"

logger "ending script"

And then do logread -f to see if it ever starts

[kavastudios]

Thank you all for your answers!

At the end the problem is that if your script (sh or php) if they have an output, you should send the output to a file instead to dev/null, otherwise the job doesn't run.

This is the first time I see this in openwrt based system. Do you think this is a feature or a glitch of the markV?

[fringes]

Redirecting standard error and standard out won't affect the running of the job. I believe the default is /dev/console, but unless you redirect both to some device (file) you can see, you won't know what's wrong. Often a script will work when run in an interactive shell, but will fail when run via cron (or init). Unless you have the standard error output, you won't have a clue what's happening.

I've worked with many Unix systems that sent the default output to the root mail. Since I haven't made that mistake in years (decades), I don't know for sure where your output was going.