Cron jobs aparecem no GNOME Scheduler mas não são executados

Question

Eu configurei o Back In Time e o MySQL Administrator para fazer um backup todos os dias às 15:00. Para ter certeza de que instalei o Gnome Scheduler para ver se esses dois aplicativos estão registrados lá. Eles são registrados no gnome scheduler, mas não executam operações de backup.

Aqui está a captura de tela do Gnome Scheduler.

Como posso resolver este problema?

UPDATE

A saída do comando crontab -l é a seguinte:

bakhtiyor@ubuntu-vm:~$ crontab -l
0 15 * * * /usr/bin/mabackup -d /home/bakhtiyor/backup/MySQL -x my-backup profile # JOB_ID_3
0 15 * * * nice -n 19 /usr/bin/backintime --backup-job # JOB_ID_2

UPDATE 2

A saída do comando grep CRON /var/log/syslog é a seguinte:

Nov 30 11:39:01 ubuntu-vm CRON[7663]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Nov 30 11:39:02 ubuntu-vm CRON[7661]: (CRON) info (No MTA installed, discarding output)

    

Answer 1

O Gnome Scheduler é apenas um belo front-end para at e crontab . E, no Ubuntu padrão, cron geralmente executa anacron , que é responsável pela execução de tarefas periódicas em máquinas que podem não estar ativas quando a tarefa é acionada.

Coisas a verificar são:

• o cron está sendo executado? %código%
• o cron está configurado? %código%
• o cron chama o anacron de / etc / crontab?
• o anacron é instalado? %código%
• o cron ou anacron registra alguma mensagem? %código%

Para a última etapa, ps -C cron pode ter arquivado syslogs mais antigos, portanto, se o grep não der resultado, tente

(cat /var/log/syslog.[0-9] ; zcat /var/log/syslog.*.gz) | grep CRON

Meu palpite é que o gnome-scheduler está configurando tarefas com as permissões incorretas (provavelmente como você e não como um superusuário) e, portanto, as reclamações aparecerão nos syslogs.

resposta para atualizar

Dado o prompt do shell no seu exemplo cat /etc/crontab , você quase certamente listou o crontab por usuário do bakhtiyor, que pode não ter as permissões para executar seus trabalhos (um tanto opacos).

As entradas do syslog mostrarão se as tarefas estão sendo executadas e, em caso afirmativo, se as tarefas se queixam.

    

Answer 2

Com base nas suas entradas de registro, parece que seus trabalhos não foram executados recentemente.

Você também deve verificar os logs do cron arquivados, porque eles podem ter sido alterados desde a última vez que foram executados.

Para depurar isso mais eu adicionaria esse trabalho, usando crontab -e

*/5 * * * * echo hello

e veja se isso lhe envia e-mail e se aparece no arquivo de log.

update: Se estiver aparecendo no arquivo de log, mas não enviando mensagens, talvez seja necessário instalar um agente de email para ver a saída de suas tarefas de backup ou executá-las com saída redirecionada em um arquivo de log. Por exemplo, você pode usar crontab -e para alterar uma linha para

0 15 * * * nice -n 19 /usr/bin/backintime --backup-job >> ~/log/backup.log 2>&1

você precisará criar o diretório ~/log .

    

Answer 3

Esta solução funcionou para mim: link

Minha configuração de trabalho foi salva no meu usuário e não na raiz porque estava usando sudo backintime-gnome e não gksu backintime-gnome .

O sudo não altera o ambiente HOME, o que causa problemas:

$ sudo env | grep ^HOME
HOME=/home/user
$ gksu env | grep ^HOME
HOME=/root

    

Answer 4

Eu tive o mesmo problema e resolvi adicionando meu nome de usuário ao grupo crontab.

1. Editar /etc/group
2. Localize a linha que contém o crontab (deve haver apenas 1 linha)
3. Adicione seu nome de usuário no final (se outros usuários estiverem na linha, separe com uma vírgula)
4. reinicializar

Answer 5

Eu tive um problema semelhante que me deu uma grande reviravolta. Supondo que cron, crontab e anacron sejam saudáveis, o principal sintoma é que a tarefa seja executada corretamente se invocada usando o botão "executar agora" do gnome-schedule, mas não seja executada como planejada quando deixada sozinha.

Isso acaba sendo principalmente um problema de ambiente gráfico. Minha recomendação é criar um wrapper para o script da tarefa, por exemplo "task-wrapper":

#!/bin/sh
gnome-terminal -x /home/username/task

Verifique se o arquivo do wrapper de tarefas é executável e crie a tarefa no gnome-schedule como um aplicativo X. Como alternativa, escreva assim:

#!/bin/sh
export DISPLAY=:0
gnome-terminal -x /home/username/task

O script / home / username / task agora será executado em uma janela de console que será fechada após a conclusão. Meus scripts normalmente requerem autenticação sudo, então eu inicio o script "task" assim:

#!/bin/sh
set -e
MESSAGE="The task script wants to ..."
gksudo --message "$MESSAGE" cd /whatever

O comando cd é inocente, o MESSAGE explica para o qual o script está solicitando autorização e 'set -e' garante que o script seja cancelado se o usuário clicar em 'Cancelar'. O restante do script pode usar chamadas simples de 'sudo' que serão bem sucedidas, a menos que muito tempo entre os comandos.

No Ubuntu 12.04, a participação no grupo crontab não parece ser necessária.