O cron job não funciona quando colocado em '/etc/cron.hourly/' mas funciona quando definido em 'crontab -e'

Question

Se eu definir meu agendador de cron através de crontab -e , o agendador funcionará corretamente. No entanto, colocar o arquivo em /etc/cron.hourly/ não funciona no meu caso.

A execução de run-parts --test /etc/cron.hourly gera o script. Além disso, o nome do script é my_sql_backup e não possui uma extensão de arquivo.

O script é root:root com a permissão 777.

O programador cron.hourly parece estar funcionando, pois essa é a saída de grep CRON /var/log/syslog :

Mar  1 11:17:01 my-instance CRON[12919]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

Além disso, se eu executasse o comando manualmente, o agendador executaria exatamente como deveria:

sudo bash -c "cd / && run-parts --report /etc/cron.hourly"

No entanto, isso parece não estar funcionando realmente. O script faz o backup do banco de dados MySQL no Google Cloud Storage, mas o armazenamento não é atualizado quando eu o verifico pelo console da Web.

Há algo que eu esteja sentindo falta aqui? Por que meu script do agendador que foi colocado em /etc/cron.hourly/ não funciona?

UPDATE

Tendo adicionado a linha echo test > /tmp/foobar.tmp ao meu script cron, descobri que o arquivo tmp está lá. Na verdade, encontrei meu próprio arquivo tmp emitido pelo script.

O conteúdo do script é o seguinte. Então, talvez o problema tenha ocorrido na execução do comando gsutil ?

# define environment variables here
sudo sh -c "mysqldump -u$MYSQL_USER -p$MYSQL_PASS $MYSQL_DBNAME --single-transaction | gzip -9 > $MYSQL_TEMPPATH" >/dev/null 2>&1
gsutil cp $MYSQL_TEMPPATH gs://$GS_BUCKET_NAME/$MYSQL_S3_DESTPATH >/dev/null 2>&1

Mais uma vez, o script funcionou bem se eu o executasse manualmente, portanto, as variáveis de ambiente estão definidas para valores corretos ...

UPDATE 2

Eu finalmente descobri que depois de obter o arquivo de log emitido pelo comando gsutil , ele tem o seguinte conteúdo:

AccessDeniedException: 403 Insufficient OAuth2 scope to perform this operation.

Eu ainda tenho que investigar porque o acesso é negado se for executado em /etc/cron.hourly/ ... Mas o problema foi em gcloud , não cron ... Obrigado pelo apoio nos comentários.

    

Answer 1

Após investigar a saída do log, finalmente descobri que o arquivo de log incluía o seguinte conteúdo, que é da gcloud execution:

AccessDeniedException: 403 Insufficient OAuth2 scope to perform this operation.

Então o problema estava no gcloud , não no cron.

Então, como evitar o erro de acesso negado no gcloud?

Para conceder acesso de VM ao Cloud Storage, siga os seguintes passos:

1. Pare sua instância de VM

2. Edite sua VM para alterar o Cloud Storage de Read para Read / Write .

3. Reinicie sua VM

E agora finalmente consegui que funcionasse como programado ...

A origem: link

    

Answer 2

Você não forneceu informações suficientes sobre o script para entender o que ele deve fazer nem por que ele pode falhar em um cron job - há algumas razões comuns.

No entanto, o título e o primeiro parágrafo da sua pergunta (sobre crontabs de usuário e root) parecem claros o suficiente, então vamos responder a isso:

Crontabs de usuário e crontabs raiz têm formatos ligeiramente diferentes e não são intercambiáveis.

Exemplo:

1 1 * * * root /bin/foo   // root crontab in /etc/cron*
1 1 * * * /bin/foo        // user crontab in /var/spool (see it using the 'crontab' command

Veja a diferença? Um crontab raiz possui um campo extra para especificar o usuário. O usuário não precisa ser root .... embora na prática seja geralmente root.

Digamos que você queira executar um trabalho de backup de banco de dados. Adicione um crontab raiz ao /etc/cron.d/ que aciona seu script de backup. Apenas acione. Um erro comum é tornar o crontab mais complexo do que precisa ser. Toda a lógica e verificação de erros e permissões e registros devem estar no script, não no crontab.