CRONTAB EXECUTA ALGUMAS TAREFAS E OUTRAS NAO [RESOLVIDO]

diogospace
(usa Debian)

Enviado em 14/01/2015 - 11:02h

Galera bom dia.
Tenho dois scripts de backup um incremental e outro full.
Configurei o cron para executa-los porém ele só executa o incremental, o arquivo full se eu fizer na mão ./full.backup vai normal.

SEGUE O CRON

################################################################
# Executa backup dos diretorios (/operação)
################################################################
#
# min hora dia mes semana usuário comando
0 18 6 * * /etc/tarefas/backup/full.backup

################################################################
# Executa backup parcial de (/operação)
################################################################
#
# min hora dia mes semana usuário comando
01 23 * * * /etc/tarefas/backup/inc.backup

plimo263
(usa Ubuntu)

Enviado em 14/01/2015 - 12:13h

Boa tarde, eu reparei que voce solicita o full em um dia especifico, ja verificou se ele roda todos os dias se voce ajustar ele para rodar todos os dias ?

att

diogospace
(usa Debian)

Enviado em 14/01/2015 - 13:06h

Vou tentar, mas, este não é o objetivo, pois deve executar em apenas 1 dia da semana

plimo263
(usa Ubuntu)

Enviado em 14/01/2015 - 17:56h

Sim entendo, somente para teste. :)

Aproveita para listar as permissoes desse script

diogospace
(usa Debian)

Enviado em 26/01/2015 - 16:44h

Boa tarde.

Desculpa a demora no envio.
segue permissões

-rwxr-xr-x 1 root root 1597 Jan 19 13:31 full.sh
-rwxr-xr-x 1 root root 2174 Out 22 22:56 inc.backup

Testei colocando *
e mesmo assim não foi.

removido
(usa Nenhuma)

Enviado em 26/01/2015 - 18:07h

Quase sempre, esse tipo de coisa ocorre por conta de variáveis de ambiente, contudo, no seu caso, pode ser ainda algo relacionado ao path pois no crontab está com full path e no teste que você disse ter feito está com relative path.

Não qual cron você está usando, mas na documentação, para onde ele manda as mensagens de erro quando elas ocorrem?

De qualquer forma, você pode tentar capturar o erro de dentro do próprio cron e mandar para um arquivo, exemplo:

# min   hour    day     month   day-of-week command

#(0-59) (0-23)  (1-31)  (1-12)  (0-6)

#------------------------------------------------------------

*/10 * * * * ( date +'[%F %T %Z]'; /etc/tarefas/backup/full.backup ) 2>&1 >> /tmp/full.bkp.log

 

Este exemplo irá executar o comando a cada 10 minutos, você deve ajustá-lo para um intervalo mais adequado ao seu caso.

Após a execução, verifique o conteúdo do arquivo /tmp/full.bkp.log, se não tiver erro algum, aí teremos mais problemas. Ligue o debug do bash (ou do shell em uso) dentro do script full.backup ( set -x ) e quando o script rodar novamente, faça a depuração dos comandos para tentar encontrar alguma anomalia.

removido
(usa Nenhuma)

Enviado em 26/01/2015 - 18:08h

Quase sempre, esse tipo de coisa ocorre por conta de variáveis de ambiente, contudo, no seu caso, pode ser ainda algo relacionado ao path pois no crontab está com full path e no teste que você disse ter feito está com relative path.

Não qual cron você está usando, mas na documentação, para onde ele manda as mensagens de erro quando elas ocorrem?

De qualquer forma, você pode tentar capturar o erro de dentro do próprio cron e mandar para um arquivo, exemplo:

# min   hour    day     month   day-of-week command

#(0-59) (0-23)  (1-31)  (1-12)  (0-6)

#------------------------------------------------------------

*/10 * * * * ( date +'[%F %T %Z]'; /etc/tarefas/backup/full.backup ) 2>&1 >> /tmp/full.bkp.log

 

Este exemplo irá executar o comando a cada 10 minutos, você deve ajustá-lo para um intervalo mais adequado ao seu caso.

Após a execução, verifique o conteúdo do arquivo /tmp/full.bkp.log, se não tiver erro algum, aí teremos mais problemas. Ligue o debug do bash (ou do shell em uso) dentro do script full.backup ( set -x ) e quando o script rodar novamente, faça a depuração dos comandos para tentar encontrar alguma anomalia.


(É falta de educação utilizar apenas maiúsculas.)

diogospace
(usa Debian)

Enviado em 26/01/2015 - 18:45h

Boa noite.
Tentei o comando que me passou, entretanto não gerou log.
Quanto ao MAIUSCULO é força do habito usar caixa alta em titulos (ABNT) ^^, mais vlw....
Continuarei tentando

removido
(usa Nenhuma)

Enviado em 26/01/2015 - 19:38h

Como nenhuma mensagem de erro é impressa em lugar algum e nenhuma tentativa de encontrar ou contornar o problema funcionaram, pode-se até afirmar que não existe problema algum nem no script nem no cron.

Ainda assim, caso encontre algo relevante, avise o fórum.


Para um modelo de trabalho mais profissional, recomendo utilizar o LaTeX e dizer adeus às formatações manuais de texto.

diogospace
(usa Debian)

Enviado em 09/02/2015 - 07:58h

Pois é,

Tentei de tudo mesmo assim não executa, nem gera log sobre falha ou algo assim, simplesmente passa direto, o estranhos é que as outras tarefas executam.

Vou procurar um método alternativo.

removido
(usa Nenhuma)

Enviado em 09/02/2015 - 09:47h

Putz! Mas que falta de sorte ...

Algumas alternativas que consegui lembrar agora:

1. Modificar o inc.backup para executar o full.backup uma vez por semana.

2. Modificar o full.backup inserindo um looping infinito e verificando a data, precisa criar também um arquivo .pid por exemplo para garantir que não haverá mais de uma instância rodando.

3. Combinar cron com o at.

Basta avisar caso precise de ajuda para implementar qualquer uma dessas alternativas.

diogospace
(usa Debian)

Enviado em 09/02/2015 - 11:38h

Bom hoje exclui o cron e iniciei ele de novo.

Vamos ver como seguirá, mas, se possível, passar como posso seguir seus passos, caso o meu não de certo já sigo o seu.


Obrigado pelo suporte