quais poderiam ser as razões para os scripts shell se matarem?

Question

Eu tenho scripts de shell como

#!/bin/bash
while true;do
   #Code HERE!
   #Pushing Data to DB
   echo "Data to DB"> /root/schip.log 2>&1
done

Este script está continuamente em execução e coletando informações no servidor e, em seguida, enviando dados para o DB (TimeStamp DB). Não sei por que, às vezes, os roteiros estão morrendo. Nos logs eu não consigo ver nada. Da mesma forma, vi no script Python. Script Python como este

import <stuff>
while True:
   #Code HERE
   #Push data to DB
   print "Data to DB"

Então, quais poderiam ser as razões ?, como eu evito? e como posso ativar os logs (em python e shell) para saber o motivo? Obrigado!

    

Answer 1

Algumas coisas que podem fazer com que um shell saia (não exaustivo):

• chamando o utilitário exit . Não vamos esquecer o óbvio
• chamando o utilitário return . No caso de bash que retornará somente se estiver em uma função ou arquivo originado.
• %código%. Isso executará exec cmd no mesmo processo, de modo a sair desse loop. O script terminará quando cmd sair.
• cmd / set -e está ativado (consulte também a variável de ambiente set -o errexit para SHELLOPTS ) e um comando sai com um erro.
• bash / set -u está ativado e uma variável não definida é referenciada.
• é definida uma set -o nounset ou DEBUG trap que chama ERR .
• Falha em especial builtins. A falha de construções especiais (como exit , set , : ...) faz com que o shell saia. No caso de eval , isso acontece apenas no modo POSIX (como quando POSIXLY_CORRECT está no ambiente ou quando chamado como bash ...) e, mesmo assim, não para todos os builtins especiais. Por exemplo, sh fará com que o shell saia.
• como mencionado por @schily , erro de sintaxe (como no código que só é alcançado condicionalmente).
• divisão por 0 (em : > / ou $((1/x)) ).
• erro interno ${array[1/x]} , por exemplo, porque foi atingido algum limite:
  • falha ao alocar memória
  • falha ao bifurcar um processo
  • tamanho da pilha excedido (por exemplo, ao usar a recursão da função)
  • Alguns outros limites no lugar via bash (o que também pode fazer com que alguns sinais sejam enviados).
• morto por outro processo. Outro processo pode chamar ulimit para matar explicitamente o intérprete do seu script.
• morto pelo sistema.
  • SIGINT / SIGQUIT. Se você pressionar kill() / ^C .
  • SIGHUP. Se o terminal estiver desconectado.
  • SIGSEGV / SIGBUS / SIGILL. O comando bash faz algo errado (um bug) ou falha de hardware (memória).
  • SIGPIPE: gravação interna ( ^\ , echo ) para um pipe ou soquete agora fechado (também pode acontecer para mensagens de erro se stderr for um pipe).

A primeira coisa a verificar seria as mensagens de erro e o status de saída.

    

Answer 2

Um erro de sintaxe em um script terminará o script.

Se o seu código de script incluir variáveis de shell que podem incluir espaços em alguns casos, isso pode causar um erro de sintaxe caso a variável do shell não esteja entre aspas duplas.

    

Answer 3

Possivelmente seu Shell está obtendo algum código externo com o "." comando.
Esse código é interpretado pela mesma instância do shell. Se esse código tiver um erro de sintaxe ou esse código executar uma "saída", o script de chamada será interrompido. É possível que esse script não seja chamado em cada loop, de modo que seu trabalho esteja em execução por algum tempo antes que ele falhe.

exemplo com um erro de sintaxe que falhará após 3 loops

#!/bin/sh
i=3
while true
do
let i=i-1
[ $i -eq 0 ] && . ./a 2>/dev/null

sleep 2
done

"a" script está faltando "fi"

if  true
then 
   echo a