Abbau von nicht (mehr) benutzten TCP-Verbindungen

[dante]

Guten Morgen zusammen,


zugegeben, der Thread-Titel ist nicht wirklich aussagekräftig, aber ich will versuchen mein Problem kurz zu erklären:

Ausgangssituation ist wie folgt:
Es geht um einen Apache-Webserver (2.2.9) auf einem Debian 32 Bit mit 2.6.26er Kernel. Er dient der Auslieferung eines Webshops.

Lokal ist dort auch die (My-)SQL-Datenbank des Shops installiert (momentan nur ein Testsystem, was leider live läuft).

Da es sich um einen eCommerce Auftritt handelt, fragt der Shop per XML-Messages Daten wie z.B. Artikelpreise bei einer Middleware zwischen Shop und ERP-System an. Dieses komplette Middlewarekonzept besteht aus einem total kranken Message Broker und der eigentlichen Schnittstelle zum Shop, letzter genannte ist eine Java-Applikation.

Nun das Problem:
Ziemlich oft (min. 1x/Tag) hängt sich die Java-Schnittstelle in einem unendlichen sleep() auf und feuert scheinbar irgendeinen Dreck gegen den Apachen. Wirklich debuggen können wir das nicht, weil das Teil weder Logs schreibt noch quelloffen für uns ist.

Fakt ist, dass ich dann immer den Apache und den Broker stoppen muss und die Schnittstelle killen muss.

ABER:
Wenn der Apache gestoppt ist, werden trotzdem noch fin_wait1 sowie last_ack Verbindungen gehalten (netstat -n |grep :80).
Diese Dinger haben scheinbar einen riesigen Timeout und werden ewig nicht geschlossen.
Fakt ist, dass die Schnittstelle wieder in ein unendliches sleep() fällt, wenn diese Verbindungen noch offen sind.
Ein

Code: Select all

ifdown eth0 && ifup eth0

sowie ein

Code: Select all

/etc/init.d/networking restart

tilgt diese Verbindungen leider nicht, es hilft (aus Zeitgründen) meist nur ein Reboot.

Wie bekomme ich diese Verbindungen ohne Reboot geschlossen? (Das Problem der Schnittstelle soll nicht Gegenstand des Threads sein, das hat sich hoffentlich bald erledigt.)

Gruß
dante

[dante]

Ein kill -3 auf den entsprechenden Java-Prozess hat leider (sowohl auf STDOUT und -ERR) nichts auf den Schirm gebracht.

Im Startskript gib es jedoch so eine Art Logging, das kann man aber total vergessen, weil dort weder ein Timestamp drinsteht noch wirkliche Fehler.

Jedoch kille ich diesen Prozess und beende sowohl den Apachen, als auch den Broker.
Daher wundert es mich, dass dort überhaupt Verbindungen offen gehalten werden.

[Joe User]

Die beiden Tools könnten eventuell helfen, ungetestet:
http://linux.die.net/man/8/tcpkill
http://linux.die.net/man/1/hunt

[dante]

Vielen Dank für eure Antworten,

wenn das Problem wieder auftritt (es lässt erfahrungsgemäß nicht allzu lange auf sich warten), werde ich die Ausgaben zu obigen Befehlen posten und tcpkill testen, hunt erscheint mir vorerst zu oversized (ich werds mir dennoch mal anschauen, sieht interessant aus).

Gruß
dante

[dante]

Hi zusammen,

ich wollte mich noch einmal zurückmelden.

Scheinbar trat das Problem auf Grund eines Fehler in unserem ERP-System auf. Das ist zwar nur ein recht wager Schuss ins Blaue, aber nach einem Update kam dieser Fehler nicht mehr vor.

Wahrscheinlich wurde ein Artikel im Web angefragt, wo dann die ERP-Queues irgendwie gemuckt haben.

Gruß
dante

[Joe User]

Danke für das Feedback. Hoffe, das war die Ursache und das Update hilft.