ruby-on-rails - job - schedule cron rails

¿Por qué mi trabajo Cron no funciona correctamente?

Question

Tengo un trabajo cron en un Ubuntu Hardy VPS que solo funciona a medias y no sé por qué. El trabajo es un script de Ruby que usa mysqldump para realizar una copia de seguridad de una base de datos MySQL utilizada por una aplicación de Rails, que luego se descomprime y se carga en un servidor remoto utilizando SFTP.

El archivo gzip se crea y se copia con éxito, pero siempre es cero bytes. Sin embargo, si ejecuto el comando cron directamente desde la línea de comandos, funciona perfectamente.

Este es el trabajo cron:

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

Esto es 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''

Revisé y verifiqué todas las rutas y están correctas. Tanto sftp.yml (credenciales SFTP) como database.yml (credenciales de MySQL) son propiedad del usuario ejecutante (implementación) con permisos de solo lectura para ese usuario (chmod 400). Estoy usando las versiones 1.1.x de net-ssh y net-sftp. Sé que no son los últimos, pero son lo que estoy familiarizado en este momento.

¿Qué podría estar causando el error de la tarea cron?

Answer 1

¿Está seguro de que el archivo temporal se está creando correctamente cuando se ejecuta como un trabajo cron? El directorio de trabajo para su script se especificará en la variable de entorno HOME o en la entrada / etc / passwd para el usuario que instaló el trabajo cron. Si la implementación no tiene permisos de escritura para el directorio en el que se está ejecutando, puede especificar una ruta absoluta para el archivo de volcado para solucionar el problema.

Answer 2

Parece que a su PATH le faltan algunos directorios, lo que es más importante /bin (para /bin/rm ). Esto es lo que usa /etc/crontab mi sistema:

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

Answer 3

¿Está cron enviando correos con registros?

De lo contrario, canalice la salida de cron a un archivo de registro.

Asegúrese de redirigir STDERR al registro.

Answer 4

Cuando los scripts se ejecutan correctamente de manera interactiva, pero no cuando lo ejecuta cron, el problema suele ser debido a la configuración del entorno de entorno en su lugar ... por ejemplo, la RUTA como se menciona anteriormente por @Ted Percival, pero puede haber otras variables de entorno.

Esto se debe a que cron no invocará .bash_profile, .bashrc o / etc / profile antes de ejecutar.

La mejor manera de evitar esto es asegurarse de que los scripts invocados por cron no hagan suposiciones sobre el entorno cuando se ejecutan. Vencer esto puede ser tan simple como incluir algunas líneas en tu script para asegurarte de que el entorno esté configurado correctamente. Por ejemplo, en mi caso tengo todos los ajustes significativos en / etc / profile (para RHEL), así que incluiré la siguiente línea en cualquier script que se ejecute bajo cron:

source /etc/profile