tomcat6 no CentOS 6: não é possível parar / reiniciar o serviço

6

Eu tenho esse problema ao parar e iniciar o tomcat6 (pacote dos repos). Eu vi com várias caixas CentOS 6 e RHEL 6.

Os sintomas são que quando eu quero reiniciar ou parar o tomcat6, ele simplesmente falha. Isso parece estar acontecendo apenas depois de ter sido executado por um tempo. Eu tenho uma nova instalação do CentOS 6 e foi capaz de reiniciá-lo, mas não mais.

Isso é o que eu vejo:

 # service tomcat6 restart
 Stopping tomcat6:                                          [FAILED]
 Starting tomcat6:                                          [FAILED]

Quando eu tento acessar /usr/sbin/tomcat6 :

# /usr/sbin/tomcat6 stop
/usr/sbin/tomcat6: line 60: /logs/catalina.out: No such file or directory

E saída de /var/log/tomcat6/catalina.out :

Oct 22, 2012 4:53:31 PM org.apache.catalina.startup.Catalina stopServer
SEVERE: Catalina.stop:
java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    at java.net.Socket.connect(Socket.java:546)
    at java.net.Socket.connect(Socket.java:495)
    at java.net.Socket.<init>(Socket.java:392)
    at java.net.Socket.<init>(Socket.java:206)
    at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:424)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

Eu pesquisei na rede e posso ver que não estou sozinho, mas não encontrei uma solução adequada, daí a minha pergunta.

BTW: Eu não estou muito familiarizado com o tomcat. Ah e: primeiro post! Então seja legal;)

    
por aairey 22.10.2012 / 17:04

4 respostas

5

Problema

O problema com o script padrão de desligamento do Tomcat é que ele simplesmente não é suficientemente difícil. Quando você estiver usando os scripts de serviço da sua distro para parar o Tomcat, você simplesmente estará chamando o próprio script de desligamento do Tomcat. O CentOS não é diferente a esse respeito. Por esse motivo, você precisa estar familiarizado com o que o script de desligamento do Tomcat pode fazer por você e, mais importante, o que ele não faz : ele não garante realmente que o Tomcat morra. Longe disso.

A coisa é que é muito fácil para o Tomcat entrar em algum tipo de situação onde ele não pode ser eliminado através de sua porta de gerenciamento .. ou mesmo através de um sinal TERM .

Vamos rever como o Tomcat pode ser eliminado por ordem de escalonamento:

  1. Matando o Tomcat por meio de sua porta de gerenciamento. Este é o padrão e é isso que o script de desligamento do Tomcat tenta primeiro. Não funcionará se o processo Java for interrompido por um motivo ou outro. Todos os relatórios que você vê na Internet, onde as pessoas reclamam que o Tomcat não irá parar, estão mais ou menos sempre neste beco. Isso não é realmente culpa do Tomcat. É muito fácil criar um aplicativo da web que faça com que todo o contêiner fique suspenso ou impossível parar por meio desse método.

  2. Matando o Tomcat enviando ao processo Java um sinal TERM . Essa é uma maneira mais strong de eliminar o Tomcat do que em (1) e o próprio script de encerramento do Tomcat tentará isso, mas será ativado apenas se você tiver definido a variável CATALINA_PID no seu Tomcat setenv.sh . (o que é altamente recomendável em qualquer caso). Matar um processo Unix / Linux enviando um sinal TERM é o padrão para o comando kill do sistema operacional. É a maneira educada de dizer um processo Unix / Linux para morrer. Infelizmente, mesmo isso, em raras ocasiões, não mata o processo do Tomcat.

  3. Matando o Tomcat enviando ao processo Java um sinal KILL . (da linha de comando do SO isso seria kill -9 <pid> ). Isto irá sempre matar o processo e deve ser o último recurso. O problema aqui é que o script padrão de encerramento do Tomcat nunca tentará isso, mesmo se o método (1) e (2) falharem. Então, se você realmente quer ter certeza de que o Tomcat foi morto, então você não tem escolha a não ser implementar seu próprio script de wrapper em torno do script de desligamento do próprio Tomcat.

Se estiver executando o Tomcat em um ambiente de produção, você realmente precisa considerar se pode viver com uma situação em que o Tomcat não morra (ou não é reiniciado) quando você executa, por exemplo, %código%. Você pode estar fazendo isso via cron e nesse caso você com certeza vai esperar um resultado determinístico, certo?

Recomendações

  • Sempre use um arquivo Tomcat service tomcat restart no qual você define setenv.sh . Isso pelo menos lhe dará o método 2 acima. CATALINA_PID do Tomcat arquivo não existe por padrão, então você deve criá-lo você mesmo.

  • Crie um script de wrapper em torno dos próprios scripts do Tomcat que garante que o Tomcat realmente morre.

No local onde trabalho, implementamos isso em todos os hosts que executam o Tomcat como um serviço. É o mesmo problema / solução para qualquer variante do Unix / Linux.

    
por 22.03.2014 / 08:23
2

Eu encontrei isso hoje. No meu caso, a causa foi um arquivo pid obsoleto.

O Tomcat começou bem depois de fazer um rm /var/run/tomcat6.pid .

    
por 24.03.2014 / 13:25
1

Eu enfrentei o mesmo problema. Para mim, aconteceu devido ao problema de permissão / proprietário do arquivo. Quando o script init.d ou /usr/sbin/tomcat6 não conseguir ler o arquivo /etc/tomcat6/tomcat6.conf , o valor de ${CATALINA_BASE} ficará vazio. Então, ${CATALINA_BASE}/logs/catalina.out na linha 60 se torna /logs/catalina.out .

    
por 21.11.2012 / 15:00
0

Estou executando o Tomcat7 no CentOS; anteriormente eu estava executando o Tomcat6.

Para reiniciar o Tomcat, eu sempre entro no diretório bin da minha instalação do Tomcat e executo o shutdown.sh, depois o startup.sh Você deve ser capaz de fazer isso como um método de fallback

    
por 23.10.2012 / 19:09