cron - alternativa pronta para produção

0

Estou testando um Raspberry Pi com o objetivo de usá-lo em um sistema de produção para registro de dados de fabricação. Tudo está funcionando bem e eu tenho gravado dados de teste no último mês.

Para redundância e gerenciamento de risco eu tenho um monte de scripts Python que precisam ser agendados.

No passado, trabalhei em ambientes do Windows Server, e o Agendador de Tarefas fez tudo o que eu precisava. Problemas de registro, novas tarefas em falha, notificações e muito mais.

Eu tenho jogado com o cron nas últimas semanas e perdi muito tempo. Os arquivos de log não são úteis e, como eu não tenho um MTA instalado, os erros reais são perdidos.

Qualquer alternativa que possa facilitar o agendamento em vez de dificultar?

Detalhes adicionados sobre o assunto:

  • Eu tentei o "> >" no passado com pouca sorte. Se essa é a maneira normal de fazê-lo, dou outro passo.
  • Os scripts do Python são executados corretamente se eu os executar manualmente. Mas assim que eu coloco no crontab ele para de funcionar e sem log eu não consigo resolver ou pelo menos entender o problema.
  • Parece ser um problema com a gravação de arquivos. As tarefas agendadas que estão funcionando são scripts python que se conectam a dispositivos bluetooth e, em seguida, registram os dados em um banco de dados MySQL.
  • O log Cron está tentando relatar a saída de tarefas, mas fazer com que o MTA não seja configurado, apenas relata o problema do MTA e fornece zero informações extras no problema real. (/var/log/cron.log este é o log principal, certo?)
  • Vou analisar o MTA, a conectividade com a Internet é um problema e pode não estar disponível em todos os momentos.
  • Meus trabalhos de registro de dados estão em "crontab -e" e tenho um trabalho que está criando arquivos de imagem que estão em "sudo crontab -e". (dois arquivos crontab diferentes eu pego)
  • Todos os meus trabalhos cron são semelhantes a estes: 00 6 * * * python /app/test.py
por Bertus Kruger 07.04.2015 / 10:02

4 respostas

3

Na verdade, o cron está pronto para produção. Tem sido testado em batalha tantas vezes que é difícil acusá-lo de mau funcionamento. O que você pode estar enfrentando é problemas resultantes de erros simples. Ajudaria muito se você especificasse quais são os seus problemas com o cron, exatamente.

Como já foi apontado pelo gaueth, você pode acrescentar >> /tmp/somefile 2>&1 ao seu comando no crontab. O que isto faz é:

  • >> /tmp/somefile significa 'acrescentar o fluxo stdout do comando ao / tmp / somefile'. Isso simplesmente grava tudo o que teria sido impresso em seu terminal no arquivo especificado. Observe o uso de >> (anexar) em vez de > (sobrescrever).
  • 2>&1 significa 'enviar stderr para stdout'. Em termos humanos: escreva a saída de quaisquer erros no mesmo local onde você escreve a saída padrão (explicada acima)

Usando isso, você terá um registro completo do que aconteceu depois que o cron executou seu script. Por favor, note que pode ser uma boa idéia fazer o script imprimir a data atual (assim como algumas outras coisas, talvez) para que você tenha esses dados no arquivo de log.

Outra coisa a ter em conta é a variável PATH . O Cron é executado em um ambiente ligeiramente diferente da sua sessão de terminal interativa, por isso, geralmente é uma boa idéia incluir a saída de echo $PATH no próprio script ou na linha crontab, assim: */20 * * * * export PATH=<paste output of echo $PATH here>; <command> .

    
por 07.04.2015 / 14:03
1

Você pode usar > /tmp/logfile 2>&1 após o comando agendado do crontab para redirecionar a saída dos comandos para um arquivo de log. Também confira o gnome-schedule para uma interface gráfica para brincar com crontab e at .

    
por 07.04.2015 / 10:08
1

O recurso de agendamento pronto para produção em sistemas Unix é cron.

Logging issues

Cron registra o que ele faz nos logs do sistema. Envia a saída de trabalhos, se houver, por email.

retrying tasks on failure

Cron não faz isso por um bom motivo. Repetir tarefas em falha é lógica de negócios. Como o sistema saberia quais falhas devem levar a novas tentativas e quando, e quais são erros fatais? Se você precisar tentar novamente, faça sua tarefa tentar novamente conforme desejado ou agendar vários trabalhos em momentos diferentes.

notifications

Veja o registro acima. Trabalhos normalmente bem-sucedidos não levam a uma notificação, apenas a uma entrada de log. Se você quiser uma notificação sobre a conclusão da tarefa, adicione-a ao script da tarefa usando seu mecanismo de notificação preferido. (Diferentemente do Windows, que possui uma GUI quase obrigatória, o Unix não executa tarefas em lote em um ambiente de GUI, portanto, não há um recurso de notificação baseado em GUI imanente.)

much more.

O que?

since I don't have an MTA installed the real errors get lost.

"Doutor, dói quando eu faço isso."

Instale um MTA . Embora algumas distribuições o omitem das instalações de base, um MTA capaz de enviar e-mails é um componente esperado de qualquer instalação Unix.

    
por 08.04.2015 / 02:13
0

Eu gostei bastante do Jenkins CI para todos os tipos de tarefas 'cron on esteróides'. Eu usá-lo para fazer e restaurar backups, limpar arquivos obsoletos / dirs, rotinas personalizadas envolvendo várias etapas, etc ... Basicamente tudo o que pode ser automatizado. O registro é ótimo e os recursos que você parece precisar estão lá por padrão ou facilmente adicionados a um dos muitos plug-ins disponíveis.

Dê um giro, você vai se perguntar como ficou sem conhecer o mordomo do IC.

    
por 07.04.2015 / 12:08