Script de shell executado com os resultados cron em arquivo de tamanho diferente do executado manualmente

Question

Eu tenho um servidor RHEL no qual estou executando um banco de dados MySQL. Eu tenho um script Bash que executa mysqldump que cria um arquivo de backup. O arquivo de backup criado ao executar o script diretamente no Bash tem 754259 bytes de tamanho. Se o mesmo script é executado via cron, tem apenas 20 bytes de tamanho.

Até onde eu sei, o cron está rodando com o mesmo contexto de usuário que eu uso quando logado para rodar o script manualmente. No entanto, dado o tamanho diferencial, isso não parece ser verdade.

Por que os tamanhos dos arquivos são diferentes ao executar o mesmo script?

O conteúdo do script de shell:

backup_path=/var/custom/db_backups
configFile=/var/custom/auth.cnf
db_name=[db_name]
date=$(date +"%d-%b-%Y")

sudo /opt/rh/mysql55/root/usr/bin/mysqldump --defaults-extra-file=$configFile $db_name | gzip -9  > $backup_path/$db_name-$date.sql.gz

Para editar o cron:

sudo crontab -e

conteúdo do arquivo cron:

12 21 * * * /var/custom/maint_plan

Isso executa o roteiro diariamente às 21h13.

    

Answer 1

O comando mysqldump não retorna nada, que é canalizado através de gzip e termina em um arquivo gzip vazio. Veja:

$ echo -n "" | gzip -9  > test.gz
$ stat -c %s test.gz
20

Isso resulta em um arquivo com tamanho 20 bytes. Portanto, o problema é o comando mysqldump . Como o crontab do root é executado, o script é executado com privilégios de raiz. sudo não é necessário. Use-o sem sudo . Apenas:

/opt/rh/mysql55/root/usr/bin/mysqldump --defaults-extra-file=$configFile $db_name | gzip -9  > $backup_path/$db_name-$date.sql.gz

    

Answer 2

O script executado via cron está falhando. 20 bytes é o tamanho de um dump vazio do MySQL.

    

Answer 3

O ambiente no qual o cron executa scripts é muito limitado. Pode não estar encontrando todos os programas necessários. Capture as variáveis de ambiente do shell em que você obtém um bom dump e leve isso para o script do cron.