Hilfe: Tomcat periodischer Absturz

[pocketom]

Auch nach langwieriger optimierung schaffe ich es leider immer noch nicht den TC längere Zeit (>24h) fehlerfrei laufen zu lassen. Der TC 6.0.20 läuft unter RHEL 5 x64, 64Bit Server VM 1.6b14. Weiterhin ist auf der Maschine ein Apache Webserver installiert. Sonst läuft da nichts, es ist also eine reine Produktivumgebung.


Diese folgende Meldung ärgert mich besonders, sie kommt jede Nacht pünklich um die selbe Uhrzeit! Ich habe mit meinem Boss (15 Jahre Unix Erfahrung!) alles durchgeschaut, crontab, etc. Wir finden nichts was regelmäßig um diese Uhrzeit läuft, auch die Netzwerkprotokolle zeigen keine Aktivität um diese Uhrzeit, kein hoher I/O Load, Backups oder sonstige Peaks, 0,0 nix... Sniffer fand auch nichts :-(

Wie kann das überhaupt sein das irgendeiner meinem TC den Port klaut (nehme an der steht sich quasi beim Neustart noch selbst im Wege)? Leider sagt der Logeintrag ansonsten nichts vernünftiges über die mögliche Ursache aus.

Dec 4, 2009 4:02:05 AM org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
Dec 4, 2009 4:02:06 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: 
/install/java/jre/jre1.6.0_16/lib/amd64/server:
/install/java/jre/jre1.6.0_16/lib/amd64:
/install/java/jre/jre1.6.0_16/:
../lib/amd64:
/usr/java/packages/lib/amd64:
/lib:
/usr/lib
Dec 4, 2009 4:02:06 AM org.apache.coyote.http11.Http11Protocol init
SEVERE: Error initializing endpoint
java.net.BindException: Address already in use<null>:8080
	at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:509)
	at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
	at org.apache.catalina.connector.Connector.initialize(Connector.java:1058)
	at org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
	at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
	at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
	at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
Dec 4, 2009 4:02:06 AM org.apache.catalina.startup.Catalina load
SEVERE: Catalina.start
LifecycleException:  Protocol handler initialization failed: java.net.BindException: Address already in use<null>:8080
	at org.apache.catalina.connector.Connector.initialize(Connector.java:1060)
	at org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
	at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
	at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
	at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)

Diesen Fehler finde ich auch öfter, allerdings tritt er nicht periodisch auf.
Wie kommt das Ding überhaupt dazu Pause zu machen? Und wie kann er plötzlich seinen Host "vergessen"?

Dec 3, 2009 7:52:39 PM org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
Dec 3, 2009 7:52:39 PM org.apache.catalina.connector.Connector pause
SEVERE: Protocol handler pause failed
java.net.UnknownHostException: de18wsprod: de18wsprod
	at java.net.InetAddress.getLocalHost(Unknown Source)
	at org.apache.jk.common.ChannelSocket.unLockSocket(ChannelSocket.java:485)
	at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:284)
	at org.apache.jk.server.JkMain.pause(JkMain.java:683)
	at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:153)
	at org.apache.catalina.connector.Connector.pause(Connector.java:1073)
	at org.apache.catalina.core.StandardService.stop(StandardService.java:563)
	at org.apache.catalina.core.StandardServer.stop(StandardServer.java:744)
	at org.apache.catalina.startup.Catalina.stop(Catalina.java:633)
	at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:676)
Dec 3, 2009 7:52:40 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina

 

[FArt]

Nachdem ich eure Infrastruktur nicht kenne, würde ich mal pauschal diesen Tipp vom Stapel lassen:
Nehmt mal eure Hardware unter die Lupe: Netzwerkkarten, Router, Hubs, Switches, Kabel, ...

Ports, die geschlossen wurden sind u.U. noch eine Zeit lang blockiert und stehen so lange nicht zur Verfügung. Das sieht man am Status TIME_WAIT (siehe 2.7 - Please explain the TIME_WAIT state - UNIX Socket FAQ)

 

[pocketom]

Hi, danke für deine Antwort. Wir sind dabei die Hardware zu untersuchen, bleibt im Moment nur noch der Switch übrig. Das ganze läuft übrigens auf eine ESX als VM. Wir haben mittlerweile aber auch alle anderen VMs von dieser ESX genommen um die Ursache weiter einzugrenzen, gebracht hats nix.

 

[pocketom]

Ok, Hardware haben wir alles durch (komplette Maschine sogar geklont und in VM-"Isolierstation" betrieben ^^) und sind nun endgültig am Ende unserer Weisheit :-(

Hat denn niemand diesen periodischen Fehler schonmal zu Gesicht bekommen? Bin für jeden Ansatz dankbar!!!

 

[kama]

Hallo,

kann es sein, dass die Konfiguration für den Server nicht ok ist? Vor allem kann das auftauchen, wenn man den TC per shutdown.sh runter fahren will aber der nicht runter gefahren wird...mit anderen Worten noch eine Instanz läuft...Genau in der server.xml nachschauen wie der shutdown-port konfiguriert ist ?....

Gruß
Karl Heinz Marbaise

 

[pocketom]

Danke für den Hinweis. Die Ursache war das der cronjob sowohl von cron, als auch 'anachron' gleichzeitig ausgeführt wurde. Warum auch immer... Das hat Nerven gekostet 🙂