Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have tried everything and I've seen other questions here regarding this but I cannot for the life of me run a python script as a cronjob.

I've tried the following.

* * * * * /usr/bin/python /home/myhome/myscript.py

All myscript.py does is a sleep for 30 seconds so I can check processes if it is running but I have yet to see it.

import time
time.sleep(30)

What am I missing? Shouldn't this run? I've even tried opening a file in /tmp and outputting there but no luck. I'm assuming its some environment variable issue but im not sure where to start.

BTW this runs fine on command line.

share|improve this question

migrated from stackoverflow.com Jan 16 '13 at 7:28

This question came from our site for professional and enthusiast programmers.

1  
What happens if you direct stdout and stderr to a file (python myscript.py > /tmp/myscript.log 2>&1? Do you see any errors? Are you sure that Python is /usr/bin/python? What do you see in your local cron log? –  larsks Jan 16 '13 at 0:02
    
@larsks No file was created in tmp. I don't see any errors. syslog shows it trying to run though. Jan 15 17:13:02 VirtualBox CRON[31926]: CMD (/usr/bin/python /home/myusername/test.py > /tmp/myscript.log 2>&1) –  KingKongFrog Jan 16 '13 at 1:14
1  
Are you able to strace it? One of the most valuable commands for diagnosing problems, I find. –  Cartroo Jan 16 '13 at 1:27

1 Answer 1

up vote 3 down vote accepted

Yes, this should run fine, assuming when you say "it runs fine on the command line" you're literally pasting the same command from the crontab entry. Things to check:

  1. Is the cron daemon actually running? (Run pidof cron)
  2. If it is running, try restarting it. (Depends on your flavour of Unix, but something like service cron restart or /etc/init.d/cron restart)
  3. If your script still doesn't run, check everything in /var/log for appropriate output - the specific file depends on your syslog configuration, but /var/log/messages and /var/log/syslog are good options if /var/log/cron doesn't exist.

Note: You'll need to be root to do most of these things - if you don't have access then you'll need to speak to the person who administers the machine.

Also, when you say you open a file in /tmp, that's probably the most reliable thing you can do to ensure it's running. Right at the start of your script (before imports or anything) add this:

with open("/tmp/testfile", "a") as fd:
    fd.write("I am running\n")

You can also check if your crontab is being correctly installed - it should be placed in something like /var/spool/cron/crontabs (that's on Ubuntu Linux, it may differ on different Unix flavours). You should see a file in there with your username which should contain your entry.

Finally, if you get really desperate you could strace your cron process to see what it's doing:

sudo strace -f -p `pidof cron`

You don't need to worry too much about the specifics, but it should be doing something every minute. If it's not then something's going quite wrong.

share|improve this answer
    
+1. But actually, you don't need to be root to do most of these things. Traditional *nix, and most modern systems, make the syslogs world-readable, allow per-user crontabs, etc. And, although it isn't required, most modern cron implementations will let you run a separate per-user instance of the cron daemon for testing. –  abarnert Jan 16 '13 at 0:33
    
Perhaps "most" was a bit of a stretch, but I just wanted to make clear that an unprivileged user couldn't expect to be able to do all those things, to try and preempt confusion over resultant errors. I've seen a number of systems where most or all of /var/log was only available to root - I assumed people set conservative permissions in case any credentials ever leaked out into log files. This does certainly differ system to system, though - I've always found the lack of consistency in logging between unices a bit lamentable. –  Cartroo Jan 16 '13 at 1:25
    
I'm getting this in the strace: [pid 1760] execve("/usr/local/bin/bash", ["/usr/local/bin/bash", "-c", "python /home/username/test.py"], [/* 5 vars */]) = -1 ENOENT (No such file or directory) –  KingKongFrog Jan 16 '13 at 1:41
1  
Looks like something has overridden the shell which cron is using to invoke jobs to /usr/local/bin/bash which, unsurprisingly, doesn't exist. The shell is specified by the SHELL environment variable and usually defaults to /bin/sh - check you're not setting a new value of this variable in your crontab, and then check /etc/crontab (can't remember if user crontabs "inherit" from this but worth a check). Also make sure your shell in /etc/passwd is set to something sensible (I assume it is or you'd have trouble logging in, but again worth checking). –  Cartroo Jan 16 '13 at 2:00
1  
As an aside, for future reference you should also check for the existence of cron.allow and cron.deny in either /etc or /var/spool/cron (depends on your system) as these can prevent some users using cron at all if they exist. However, your error seems to point to the wrong shell being used. –  Cartroo Jan 16 '13 at 2:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.