Your commands should actually work, however it's not as I would do it.
Instead try :-
sudo crontab -e -u root
then to list :-
sudo crontab -l -u root
As a general rule I go to a great deal of trouble to never run a root shell. When I do I use sudo -s
rather than sudo su
.
When you exit from vi you should see two lines :-
crontab: no crontab for root - using an empty one
crontab: installing new crontab
If you don't get those two lines you have serious troubles. If you do and then the list command doesn't show anything I would suspect permission troubles.
I also wouldn't use your example line as you are asking the system to run "sayhi.sh" once a minute all day, every day. I also wonder about the path "/sayhi.sh" - do you really have the script right up the top of your boot drive? That's not a good idea either or do you perhaps mean "~/sayhi.sh" which in this case would be in roots home directory (usually /var/root) or do you mean your home directory. In crontab files it's best to explicitly code the entire path, regardless.
You do also realise that tany output of the cron job will not go to any terminal but will instead be emailed to root (by default).
If you want to check that cron is running tasks a simple
*/5 * * * * echo "CRON" > /Users/myname/.cronout
will do that (the first field runs the task a much more reasonable every 5 minutes).
The crontabs themselves are stored in /usr/lib/cron/tabs. /usr/lib/cron
is actually a link to /var/at
and if you go there you will find the tabs
directory and also the cron.deny
file. Check that nobody has added root to that and if you still have no joy then you might try :
echo > /var/at/tabs/root
which should create an empty file that you might then be able to edit.
Open terminal and run this:
sudo fs_usage | grep cron
I'd run it using tmux or screen so that you can detach and check later. Depending on how many cron jobs you have, this could generate a lot of messages and you'll want to not run it where a runaway process could cause harm. (backup, check filesystems for space, etc...)
You can also use mdfind
to see if you can locate the file/script/package that is calling crontab (perhaps) and correlate that with the times when the actual filesystem changes are happening.
mdfind crontab
Best Answer
Your crontab suggests that at 3 minutes past every hour from 04:00 through 22:00, invoke
python
to run/me/radio_alarm.py
If that's correct, and there are no other problems that we can't see*, the following correction should work:
03 04-22 * * * /usr/bin/python /me/radio_alarm.py
It is necessary to specify the complete path to
python
because the "cron user" does not have the same $PATH environment that you do under your user name.* I assume that you have successfully run your script from the command line. If that is the case, you've probably cleared most of the potential errors below, but just in case here are the "usual suspects":
chmod 755 /me/radio_alarm.py
)#!/usr/bin/python
)homebrew
, etc.)Finally, it never hurts to capture any
stderr
output while you're testing a new script. You can easily add an "error log" to your script as follows:This will redirect any error output from your script to the file
cronjoblog
in your user's home directory.Hope that helps. Let us know if you have further issues or questions.