0

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!

dannymcc
  • 2,717
  • 10
  • 48
  • 72
  • 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. – user9517 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

1 Answers1

0

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.

gWaldo
  • 11,957
  • 8
  • 42
  • 69
  • 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/` 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 ` 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. – phemmer Jul 23 '12 at 12:08
  • 'su -c root ./import_premvet.sh' results in 'Unknown id: ./import_premvet.sh' – dannymcc Jul 23 '12 at 12:08
  • That command is trying to run `root` as the `./import_premvet.sh` user. The command and username should be the other way around. If your command has parameters separated by spaces, enclose the command in quotes. (Single or double quotes, depending on whether you want bash to interpret variables inside the quotes.) – Ladadadada Jul 23 '12 at 12:12
  • Sorry! My mistake. 'su -c ./import_premvet.sh root' results in 'bash: ./import_premvet.sh: /usr/local/bin/sh: bad interpreter: No such file or directory' – dannymcc Jul 23 '12 at 12:21
  • Correcting the fist line of the script to '#!/bin/sh' succeeds. – dannymcc Jul 23 '12 at 12:22