maneira infalível de detectar se o processo java está sendo executado

Question

Eu tenho um processo java que é executado continuamente, que às vezes, por motivos que ainda não foram totalmente depurados, não é possível. Então, eu também tenho um cron job que procura o processo a cada 5 minutos e se ele achar que o processo não está sendo executado, ele chama um script para reiniciá-lo.

O problema é que, às vezes, de vez em quando, o script de check-up recebe um falso negativo - ele acha que o processo não está sendo executado quando, na verdade, é. Eu não vi nenhuma consistência quando isso acontece. Mas eu preciso de uma maneira completamente infalível para verificar se o processo está sendo executado.

O que estou fazendo atualmente é:

if ! pgrep -f '/path/to/XML2DB.jar -n' > /dev/null
then
    nice -n 19 java -Xmx2024M -jar /path/to/XML2DB.jar -n > /dev/null 2>/dev/null &
    echo "" | mail -s "$HOST: xml2db was found not running, is being started" [email protected]
fi

Antes do pgrep, estávamos usando ! ps ax | grep -v grep | grep "XML2DB.jar -n" > /dev/null , mas isso também dava falsos positivos.

A versão do Linux é Scientific Linux SL release 3.0.9 (SL) e LSB Version é 1.3.

Obrigado antecipadamente!

    

Answer 1

Não há como verificar de forma confiável e útil que um processo não relacionado está em execução: uma condição de corrida é sempre possível. Mesmo que você encontre uma maneira de detectar se o processo em que está interessado está em execução, ele pode ser eliminado imediatamente depois de ser visto ou, por outro lado, pode ser iniciado imediatamente depois que você o perdeu.

Se você controlar o programa ou a maneira como ele é executado, é possível reservar um recurso exclusivo, como um bloqueio de arquivo. No entanto, se você controlar a maneira como o programa é invocado, há uma maneira mais simples de controlá-lo: monitorá-lo de seu pai. Um processo é informado quando seu filho morre.

A maneira mais simples de garantir que um processo esteja sempre em execução é reiniciá-lo em um loop.

# sleep 1 avoids a tight loop if the process systematically fails to start
while sleep 1; do
  nice …
  ret=$?
  if [ $ret -le 127 ]; then
    msg="… exited with status $ret"
  else
    msg="… exited on signal $((ret-128))"
  esac
  mail -s "$msg" "$USER"
done

Existe um software de monitoramento mais robusto e mais potente. Veja Como definir o monitoramento adequado dos meus serviços de forma automatizada? Então, se um deles travar, ele reinicia automaticamente?

    

Answer 2

A técnica ps ax | grep -v grep | grep "XML2DB.jar -n" tem uma condição de corrida: as instâncias de grep podem ou não começar a tempo para ps para vê-las, para que você obtenha contagens imprecisas: consulte aqui e aqui . Você não é o primeiro a ter problemas para usá-lo.

Eu fiz um strace pgrep somepattern em uma caixa RHEL para descobrir o que o pgrep está fazendo. Ele indica todos os diretórios de processo em /proc e abre /proc/<PID>/cmdline para alguns PIDs e lê o conteúdo, presumivelmente para corresponder ao padrão fornecido na linha de comando pgrep . Eu estou acenando minhas mãos aqui, mas aposto que também há uma condição de corrida.

A única solução infalível para isso é fazer com que o processo Java tente criar um " diretório de bloqueio ". A criação de diretórios é atômica para processos do usuário. Se o diretório de bloqueio já existir, saia com uma mensagem de erro, caso contrário. comece. Depois de criar o diretório de bloqueio , ele deve gravar seu PID em um arquivo no bloqueio de diretório.

Você pode usar o PID no arquivo para verificar se o programa Java está sendo executado com kill -0 $(cat /whatever/lockdir/PIDfile) - se o processo não existir, kill sairá com um status diferente de zero.

O truque é passar o PID para o programa Java em sua linha de comando:

exec java blah blah -mypid $$

Você ainda precisa ser muito cuidadoso com erros ou exceções que envolvam a criação do diretório de bloqueio e na interpretação do kill -0 e ao remover o arquivo PID e o diretório de bloqueio, mas você terá problemas com qualquer outro método.