Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

When I run a python script in a terminal it runs as expected; downloads file and saves it in the desired spot.

sudo python script.py    

I've added the python script to the root crontab, but then it runs as it is supposed to except it does not write the file.

$ sudo crontab -l
> * * * * * python /home/test/script.py >> /var/log/test.log 2>&1

Below is a simplified script that still has the problem:

#!/usr/bin/python

scheduleUrl = 'http://test.com/schedule.xml'
schedule = '/var/test/schedule.xml'

# Download url and save as filename
def wget(url, filename):
    import urllib2
    try:
        response = urllib2.urlopen(url)
    except Exception:
        import traceback
        logging.exception('generic exception: ' + traceback.format_exc())
    else:
        print('writing:'+filename+';')
        output = open(filename,'wb')
        output.write(response.read())
        output.close()

# Download the schedule
wget(scheduleUrl, schedule)

I do get the message "writing:name of file;" inside the log, to which the cron entry outputs. But the actual file is nowhere to be found...

The dir /var/test is chmodded to 777 and using whatever user, I am allowed to add and change files as I please.

share|improve this question
    
It is a rights issue. I figured out that when I have the files I want to write present and I chmod those to something like 666 then everything works fine. So how to get python to be able to write as well? I thought by adding the script to the sudo crontab it would run with some priviledges I'd usually have when sudoing myself... –  Ruud Nov 28 '11 at 22:07
    
You can't sudo when you are not there. This command gives you temporary elevated rights, predicated on entry of the required password. –  david6 Nov 29 '11 at 1:52
    
david6, I thought that by adding it using sudo crontab filename.cron that the scripts would be executed as if executed using sudo. So with elevated rights. This is not correct? –  Ruud Nov 29 '11 at 11:14
    
The command sudo crontab -l will report your current crontab settings. The 'sudo' would NOT effect anything. You would need to try something like using 'cron' (for root user) [Not Recommended] - you should instead be looking at: chroot. –  david6 Nov 29 '11 at 22:43
    
david6; you are wrong. sudo crontab -l and crontab -l display different entries. And so far I'm not getting permission denieds for tasks in the sudo crontab on tasks that do display this message in the current user crontab. –  Ruud Dec 2 '11 at 7:33

2 Answers 2

What works for me

Crontab

#Borrowed from anacron
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
#End borrowed from anacron

* * * * *   python /home/username/somedir/test.py

Python script

scheduleUrl = 'http://example.com/index.html'
schedule = '/tmp/test.html'

# Download url and save as filename
def wget(url, filename):
    import urllib2
    try:
        response = urllib2.urlopen(url)
    except Exception:
        import logging
        logging.exception('error')
    else:
        print('writing:'+filename+';')
        output = open(filename,'wb')
        output.write(response.read())
        output.close()

# Download the schedule
wget(scheduleUrl, schedule)

Added environment variables. Used tmp instead of var to verify there weren't permissions issues.

share|improve this answer
  • Check log files grep -i cron /var/log/syslog
  • Add an empty line to the end of the crontab, This has been a known bug for ages, not sure if it is solved.
  • Remove the 2>&1 from the command line until it works as designed. Any usefull errors are redirected to a file that is not created; effectively lost.
  • Check if root received mail (eg. using mutt or in /var/spool/mail). Error messages from cron are sent to system email by default.

Also:

  • Reconsider the 777 permissions as soon as possible. When running from root, 755 root:root should be sufficient to be able to check the logs from unprivileged user)
  • Reconsider running the script from root, it is bad practise.
share|improve this answer

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.