(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
e.g.:
1 5 * * * /path/to/script/I/want/to/run.sh > /dev/null 2>&1
Providing your shell script has:
#!/bin/sh
or:
#!/bin/bash
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 at...um... /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 crontab....so 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!)
I am still not sure of the mechanism they use to email out though! 
