Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

On my server I am getting the following error when running one of my cron tasks:

CRON[9913]: (CRON) error (grandchild #9915 failed with exit status 127)

The server is running Ubuntu-1104-natty-64-minimal.

I am using the Whenever gem along with the Backup gem, although the cron task that is failing is only using the Whenever gem to write the crontab file.

The cron task script (for Whenever) is as follows:

set :output, "#{path}/log/cron.log"

every 2.minutes do
  command "cd /var/www/outofhours && /usr/local/bin/rake fetch_incomingcalls RAILS_ENV=production"
end

every 1.day, :at => '11:05am' do
  command "cd ~/ && ./import_premvet.sh"
end

In the above script, the first script (every 2.minutes do) works perfectly. However, the second (every 1.day) script fails with the error.

The script that it should be running is:

#!/bin/sh
# Untar premvet_sync database and dump into local mysql server.

echo "Finding latest backup directory"
dir=$(ls -td1 /root/backups/premvet_sync/* | head -1)

echo "Opening latest backup directory"
cd $dir

echo "Latest: $dir"

echo "Uncompress premvet_sync.tar"
tar -xvf premvet_sync.tar

echo "Dig down into correct directory"
cd $dir/premvet_sync/databases/MySQL

echo "mysqldump the compressed database file"
gunzip < premvet.sql.gz | mysql -u root -pPASSWORD premvet

echo "Done."

The permission of the above script are set to:

-rwxrwxrwx 1 root root  510 2012-07-23 11:31 import_premvet.sh

I have also tried changing the above script's first line to:

#!/usr/local/bin/sh

When configuring the Whenever and Backup gem originally I ran the following command to get them working correctly:

sudo ln -s /usr/local/bin/ruby /usr/bin/.

It's important to note that when running the script directly when logged in as root it succeeds.

Cron Log

This is how the task appears in my crontab -e view:

2 13 * * * /bin/bash -l -c 'cd ~/ && ./import_premvet.sh &>/tmp/cronjob.log >> /var/www/outofhours/log/cron.log 2>&1'

When running tail -f /tmp/cronjob.log I get:

tail: cannot open `/tmp/cronjob.log' for reading: No such file or directory

The contents of #{path}/log/cron.log is:

Scraping Calls

Which is a success message from the first cron task. No mention of the second (failing) task/script.

Any help would be appreciated!

share|improve this question
    
If it works in Root but not anywhere else, it's a sign that it might be permission problems. –  qweet Jul 23 '12 at 10:40
    
I've added the permissions of the script to my question. –  dannymcc Jul 23 '12 at 10:42
1  
can you add &>/tmp/cronjob.log to the end of the cron line to capture the output and report back ? IS there anything interesting in the #{path}/log/cron.log which would presumably help narrow dowh where the error is. –  Iain Jul 23 '12 at 10:58
    
The contents of #{path}/log/cron.log is the success message from the first script. Nothing else. I'll add the /tmp/cronjob.log now. –  dannymcc Jul 23 '12 at 11:59
    
I've updated my question. –  dannymcc Jul 23 '12 at 12:06
add comment

1 Answer 1

Typically the cause for a script to work in your account but fail in a cron are:

  • environment variables are not set
  • gems not installed or accessible by the cron user
  • lack of permissions or a different starting path (home) in the script.

I recommend that you 'su' to your cron user and run your script to see how it fails.

share|improve this answer
    
I'm sorry but I though cron always runs as root - is that incorrect? –  dannymcc Jul 23 '12 at 10:42
    
I think that it typically runs as the cron user, but I might be wrong... –  gWaldo Jul 23 '12 at 11:08
2  
It depends on which crontab you are talking about. The jobs in /etc/crontab and anything in /etc/cron.* run as root. Each user also has their own crontab in /var/spool/cron/crontabs/<username> which run as that user. Root is a user and has a crontab in that directory and the jobs in it run as root. You can use su -c <command> <username> to run a job as a different user from a root crontab. –  Ladadadada Jul 23 '12 at 11:45
    
'su -c cron ./import_premvet.sh' results in 'Unknown id: ./import_premvet.sh' –  dannymcc Jul 23 '12 at 12:07
1  
@Ladadadada is correct (on the users thing). But an su wont give you the same environment cron runs commands with. The environment is inherited from init on boot. –  Patrick Jul 23 '12 at 12:08
show 4 more comments

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.