Full Version: Crontab problem....??
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I am new to cron and bash but have it set up and running on a raspbian pi, but the same approach won't work with Xbian.

If I execute the bash script from the CLI prompt ("sudo bash /home/pi/") it works! - But adding the following with crontab -e and nothing happens on a reboot.

What have I done wrong? Huh


@reboot sudo bash /home/pi/
Always include full paths and leave the sudo. Cron is already ran as root.
(17th Sep, 2015 07:46 PM)CurlyMo Wrote: [ -> ]Always include full paths and leave the sudo. Cron is already ran as root.

Isn't /home/pi/ a full path ? What is missing? Sad
bash isn't Wink
Thanks for the pointer.....

Now i have....


@reboot /usr/bin/python /home/pi/
@reboot /bin/bash /home/pi/

Still no joy.

Here are the contents of ""

#! /bin/bash
#Script to send Cinema2 reboot alert.
sudo /usr/sbin/ssmtp my mail@my.domain.somewhere < /home/pi/reboot.txt

The "" (which I have not set up to send mail) sends an email with a complaint about GPIO import (posted separately on the forum as someone else had the same issue with no resolution), but "" doesn't seem to send an email at all. I did a lot of research to get this far and it works under Raspbian. Why won't it work with Xbain ??? What else do I need to learn?
What does the cron log say?

Also, just test cron one minute ahead and with simple scripts like this:
echo "ok" > /tmp/crontest
Cron has its own log? - I learn something new every day !

Your test worked OK (from terminal).

So I set out to track this log down. According to this site.... It is in var/log/cron.log, only that doesn't exist on Xbian!.....?

So I thought that maybe logging needs to be enabled, so off I go in search of that nugget of info....According to this page should be in /etc/syslog.conf...Guess what, that doesn't exist on Xbian either.

To make matters even stranger, I got an email from 'anacron' today (apparently a daily mail, which I didn't set up or enable as far as I can tell).

So the one message I want won't work and I get at least 2 that I didn't want - What on earth is going on here???

Also, while on the topic, what is the difference between crontab -e and sudo nano /etc/crontab. They are clearly not editing the same file! ???
Quote:Your test worked OK (from terminal).
The idea is to make it work from cron.
Your test didn't work. Sad

I tried it via crontab -e and via /etc/crontab (which should I be using BTW? - They are different! Huh)

I noticed the anacron messages were not in crontab -e but were in /etc/crontab, so they are now commented out. Smile I am still not sure of the mechanism they use to email out though! Confused

I also noticed that 'root' was prefixed in the anacron entreis in /etc/crontab and tried that too, but nothing. Sad
Are you sure cron is running?
# pgrep cron

This example works here:
# Edit this file to introduce tasks to be run by cron.
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# For more information see the manual pages of crontab(5) and cron(8)
# m h  dom mon dow   command
16 11 * * * echo "ok" > /tmp/cron

# ls -Al /tmp/cron
-rw-r--r-- 1 root root 5 Sep 19 11:16 /tmp/cron
THanks for getting back quickly on this, I appreciate the help and always learn from you! Smile

(19th Sep, 2015 07:18 PM)CurlyMo Wrote: [ -> ]
# pgrep cron

That gives.....

xbian@cinema ~ $ pgrep cron

Your example looks like the ones I have tried (remember it is working under Raspbian). Looks like it was done with crontab -e right?

# ls -Al /tmp/cron
-rw-r--r-- 1 root root 5 Sep 19 11:16 /tmp/cron

Now at this point I get something completely different.......


xbian@cinema ~ $ ls -Al /tmp/cron
ls: cannot access /tmp/cron: No such file or directory
cron does time based triggers so you'll have to wait until the time arrives. So are you sure your time is correct? Also, are you editing cron as root or as XBian user? It should be edited as root.
Aha! - Good question. Wink

$date shows the clock at GMT and not BST, so that might be the cause of the tests failing, I guess something happened going back to wheezy when I got no sound from the Jessie upgrade (will be trying that again in a day or two)......

However, would a wrong time setting also stop the @reboot cron job running correctly beacuse here we have no time parameters at all?

I have been editing as Xbian with just 'crontab -e' but using 'sudo nano /etc/crontab' - so will try again this afternoon/evening as root, I have a lot of other things that need doing now Sad

I have a spare DS3231 hardware clock board and will add it later on today if I get time.

Ironically, that cron job I set up on Raspbian is to sync the DS3231 with NTP at reboot or once a week!


It's started working! - I don't know why, I was having a problem getting the i2c HWclock to work (looks like an 'iffy' module, have ordered more) but when I got as far as I could with that I checked my emails and there they were, lots of reboot messages from the work on i2c! - Odd.

UPDATE 2 ...
I also got rid of the annoying email from Python. Just add ">/dev/null 2>&1" without the quotes after the crontab entry and ta-da! = No more emails from that!
I will look into doing the same with the 'daily' message when I find it! Wink

Thanks for the help and pointing me in the right direction! - I have learned some new stuff this week! Smile
(19th Sep, 2015 12:43 AM)Skywatch Wrote: [ -> ]To make matters even stranger, I got an email from 'anacron' today (apparently a daily mail, which I didn't set up or enable as far as I can tell).

Also, while on the topic, what is the difference between crontab -e and sudo nano /etc/crontab. They are clearly not editing the same file! ???

You got an email because that is the default action when a cron job is set up (assuming there is an output of some sort as a result of the job being run). By directly editing /etc/crontab you effectively set up a bespoke cron job, hence you now get a daily email from cron with the result of what it did. To not get an email when cron does something, tell it to redirect all reports and errors to /dev/null

1 5 * * * /path/to/script/I/want/to/ > /dev/null 2>&1

Providing your shell script has:
if you really want bash, as the very first line, there is no need to put /bin/bash in your crontab line - the script will run as a shell script.

Runnning "crontab -e" invokes the editor of your choice (set in your enviornment, personally I use vi but the default on most systems these days seems to be nano) and automatically opens up the crontab of the user running the crontab -e command. So if you're root it will open up root's crontab. Which is is actually located at /var/spool/cron/crontab/root If you run it as a different user (e.g. pi) it will open up pi's crontab at /var/spool/cron/crontab/pi Note: the crontab file is created the first time a cron job is set up for that user, there is no file there by default. But the really importat thing about running "crontab -e" is that the crontab you create is error checked before it is installed, which it isn't if you simply edit the crontab file by hand.

Running "sudo nano /etc/crontab" means you're editing the system-wide crontab located /etc/crontab. And there is no error checking!! Editing this file is not a good thing to do if you're trying to run general cron jobs. Usually the system-wide crontab simply runs all the anacron scripts (daily, weekly, hourly). If you want to run a bespoke cron script edit the crontab of the user you want to run the job (probably root in most cases). The latter part there is important because the cron scrip will run with the permissions of the user - who may or may not have permission to do what it is you're trying to do. Usually when a cron job doesn't run it's either because the paths are missing or beacuse the user doesn't have the correct permissions to do it. Putting "sudo" in a script being run by cron is pointless as sudo then requires a password to be entered and the whole point of cron is that it runs unattended. If the script has to be run as root then it should be in root's crontab, not pi's and not the system default. I think the @reboot command has to be run as root (could be wrong). To edit root's crontab if you're not actually logged in as root: "sudo crontab -e -u root"

[ACK - my bad, your first post says the script works if you manually run it]
As for getting your particular cron job to work...if I interpret correctly the shell script doesn't work even if you run it from the command line? In which case it'll never work from a crontab. Do you have ssmtp installed? What is the output of "which ssmtp" or "which mail"? If yes, have you configured /etc/ssmtp/ssmtp.conf? From what I understand about ssmtp (I've never used it so I could be wrong here), to send an email the command line (which is what should appear in your script) should be:
/path/to/mail mail@my.domain.somewhere < /home/pi/reboot.txt
not sure where the "my" part of your command comes in.

Remember, crontab will also send you an email to say that it has performed the cron job, so either put "> /dev/null 2>&1" at the end of the crontab line pointing to your script. Or, (as we know that cron is successfully sending out emails!) if all you want is an email to note that the machine has rebooted and nothing more, simply, have a crontab entry that says:
@reboot /bin/echo "I have rebooted"

Note though: some googling on @reboot seems to imply that it might be broken in some versions of if you can get the script to run manually, but still nothing happens on reboot it could be that the crontab doesn't handle @reboot. So try a different tact: add the path to your (working) shell script at the end of your /etc/rc.local file (but before the "exit 0" line!). This file is run after all the other startup scripts when the machine starts. So once all is up, your shell script will be run when the machine reboots. Personally I've never used @reboot, I always add things to /etc/rc.local if I want them to run at startup.

Hope that helps.
P.S. To see what a crontab contains without editing it the command is: crontab -l That shows your crontab, to see some other user's crontab: crontab -l -u user (but you'll need to be root do do that!)
WoW! = Big Grin

Thank you Alcina for taking what must have been a long time to reply like that.

It is really well explained and I shall read it again a few more times before I go to bed. You never know it might just sink in! Smile

I guess we must have crossed though as it seems to be working for me now, but your post should be made a 'sitcky' for people trying to understand cron.

It worked easily for me with Raspbian, but I had real issues with Xbian and the same scripts (as you no doubt saw). Maybe I did finally edit as root and that was the cure, I can't think of anything else!

Thank you!

Reference URL's