Por que meu Cron Job não funciona corretamente?

Question

Eu tenho um cron job em um Ubuntu Hardy VPS que funciona apenas pela metade e não consigo entender o porquê.O trabalho é um script Ruby que usa mysqldump para fazer backup de um banco de dados MySQL usado por um aplicativo Rails, que é então compactado e carregado em um servidor remoto usando SFTP.

O arquivo gzip é criado e copiado com sucesso, mas sempre tem zero bytes.No entanto, se eu executar o comando cron diretamente da linha de comando, ele funcionará perfeitamente.

Este é o cron job:

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

Este é 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'

Eu verifiquei e verifiquei todos os caminhos e eles estão corretos.Ambos sftp.yml (credenciais SFTP) e banco de dados.yml (credenciais MySQL) pertencem ao usuário em execução (deploy) com permissões somente leitura para esse usuário (chmod 400).Estou usando as versões 1.1.x do net-ssh e net-sftp.Eu sei que eles não são os mais recentes, mas são os que estou familiarizado no momento.

O que poderia estar causando a falha do cron job?

Answer 1

Tem certeza de que o arquivo temporário está sendo criado corretamente ao ser executado como um cron job?O diretório de trabalho do seu script será especificado na variável de ambiente HOME ou na entrada /etc/passwd do usuário que instalou o cron job.Se a implantação não tiver permissões de gravação para o diretório em que está sendo executada, você poderá especificar um caminho absoluto para o arquivo de despejo para corrigir o problema.

Answer 2

Quando os scripts são executados corretamente de forma interativa, mas não quando executados pelo cron, o problema geralmente ocorre devido às configurações do ambiente em vigor ...por exemplo, o PATH já mencionado por @Ted Percival, mas podem ser outras variáveis ​​de ambiente.

Isso ocorre porque o cron não invocará .bash_profile, .bashrc ou /etc/profile antes de executar.

A melhor maneira de evitar isso é garantir que quaisquer scripts invocados pelo cron não façam nenhuma suposição sobre o ambiente durante a execução.Superar isso pode ser tão simples quanto incluir algumas linhas em seu script para garantir que o ambiente esteja configurado corretamente.Por exemplo, no meu caso, tenho todas as configurações significativas em /etc/profile (para RHEL), então incluirei a seguinte linha em qualquer script a ser executado no cron:

source /etc/profile

Answer 3

Parece que o seu PATH estão faltando alguns diretórios, o mais importante /bin (para /bin/rm).Aqui está o que meu sistema /etc/crontab usa:

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

Answer 4

O cron está enviando e-mails com logs?

Caso contrário, canalize a saída do cron para um arquivo de log.

Certifique-se de redirecionar STDERR para o log.