为什么我的Cron工作不能正常工作?

时间:2008-08-16 16:15:18

标签: ruby-on-rails ruby linux ubuntu cron

我在Ubuntu Hardy VPS上有一个cron工作,只有一半工作,我无法理解为什么。这个工作是一个Ruby脚本,它使用mysqldump来备份Rails应用程序使用的MySQL数据库,然后使用SFTP将其压缩并上传到远程服务器。

成功创建并复制了gzip文件,但它始终为零字节。但是,如果我直接从命令行运行cron命令,它就能完美运行。

这是cron的工作:

PATH=/usr/bin
10 3 * * * ruby /home/deploy/bin/datadump.rb

这是datadump.rb:

#!/usr/bin/ruby
require 'yaml'
require 'logger'
require 'rubygems'
require 'net/ssh'
require 'net/sftp'

APP        = '/home/deploy/apps/myapp/current'
LOGFILE    = '/home/deploy/log/data.log'
TIMESTAMP  = '%Y%m%d-%H%M'
TABLES     = 'table1 table2'

log        = Logger.new(LOGFILE, 5, 10 * 1024)
dump       = "myapp-#{Time.now.strftime(TIMESTAMP)}.sql.gz"
ftpconfig  = YAML::load(open('/home/deploy/apps/myapp/shared/config/sftp.yml'))
config     = YAML::load(open(APP + '/config/database.yml'))['production']
cmd        = "mysqldump -u #{config['username']} -p#{config['password']} -h #{config['host']} --add-drop-table --add-locks --extended-insert --lock-tables #{config['database']} #{TABLES} | gzip -cf9 > #{dump}"

log.info 'Getting ready to create a backup'
`#{cmd}`    

# Strongspace
log.info 'Backup created, starting the transfer to Strongspace'
Net::SSH.start(ftpconfig['strongspace']['host'], ftpconfig['strongspace']['username'], ftpconfig['strongspace']['password']) do |ssh|
  ssh.sftp.connect do |sftp|
    sftp.open_handle("#{ftpconfig['strongspace']['dir']}/#{dump}", 'w') do |handle|
      sftp.write(handle, open("#{dump}").read)
    end
  end
end
log.info 'Finished transferring backup to Strongspace'

log.info 'Removing local file'
cmd       = "rm -f #{dump}" 
log.debug "Executing: #{cmd}"
`#{cmd}`
log.info 'Local file removed'

我已经检查并仔细检查了所有路径并且它们是正确的。 sftp.yml (SFTP凭据)和 database.yml (MySQL凭据)均由执行用户(部署)拥有,该用户具有该用户的只读权限(chmod 400) )。我正在使用net-ssh和net-sftp的1.1.x版本。我知道它们不是最新的,但它们是我现在所熟悉的。

什么可能导致cron作业失败?

4 个答案:

答案 0 :(得分:9)

当脚本以交互方式正确运行但不是由cron运行时,问题通常是因为环境环境设置到位...例如@Ted Percival提到的PATH as alrady,但可能是其他环境变量。< / p>

这是因为cron在执行之前不会调用.bash_profile,.bashrc或/ etc / profile。

避免这种情况的最佳方法是确保cron调用的任何脚本在执行时不会对环境做出任何假设。过度使用可以像在脚本中包含几行一样简单,以确保正确设置环境。例如,在我的情况下,我在/ etc / profile(对于RHEL)中有所有重要设置,因此我将在cron下运行的任何脚本中包含以下行:

source /etc/profile

答案 1 :(得分:4)

您的PATH看起来缺少一些目录,最重要的是/bin/bin/rm)。以下是我的系统/etc/crontab使用的内容:

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

答案 2 :(得分:2)

您是否确定在作为cron作业运行时正确创建了临时文件?脚本的工作目录将在HOME环境变量中指定,或者在安装cron作业的用户的/ etc / passwd条目中指定。如果deploy对其正在执行的目录没有写权限,则可以指定转储文件的绝对路径来解决问题。

答案 3 :(得分:0)

cron是否发送包含日志的电子邮件?

如果没有,将cron的输出传递给日志文件。

确保将STDERR重定向到日志。