XMPP: SocketException: Keine Route zum Zielrechner (nach Verbindungsabbruch)

[Lyra]

Moin *,

ich habe eine Konfiguration, in welcher als Reaktion auf bestimmte Ereignisse eine Nachricht in einen Chatroom (XMPP/Jabber) abgesetzt wird. Konkret geht es um den Statuswechsel für die Verfügbarkeit von bestimmten Clients im WLAN.

Eigentlich (TM) funktioniert das zuverlässig, auch über mehrere Tage hinweg. Das Problem scheint erst dann aufzutreten, wenn es zu einem Verbindungsproblem gekommen ist. Ab da wird allerdings bei jedem Chatversuch eine Exception geworfen, auch wenn die Verbindung längst wiederhergestellt ist und ich beispielsweise per telnet systemseitig eine Verbindung herstellen kann.

Wenn dieser Zustand einmal eingetreten ist, scheint nur noch ein Neustart von openHAB verlässlich zu helfen. Von allein erholt sich die Instanz nicht.

# java -version
openjdk version "1.8.0_141"                                                                                                                                                
OpenJDK Runtime Environment (build 1.8.0_141-b16)                                                                                                                          
OpenJDK 64-Bit Server VM (build 25.141-b16, mixed mode)

# grep 'PRETTY_NAME' /etc/os-release
PRETTY_NAME="CentOS Linux 7 (Core)"

# cat /opt/openhab2/conf/services/xmpp.cfg
xmpp:servername=jabber.<domain>
xmpp:username=smarthome
xmpp:password=<password>
xmpp:securitymode=required
xmpp:port=5222
xmpp:chatroom=smarthome@conference.<domain>
xmpp:chatnickname=smarthome
xmpp:chatpassword=<password>

# cat /opt/openhab2/conf/rules/presence.rules
rule "mobile-<user>-presence"
when
  Item Mobile<user>_Online changed
then
  chatXMPP( "Mobile<user> - state changed: " + Mobile<user>_Online.state)
end
<...>

Die Exception (in diesem Beispiel aufgetreten nach einem Abbruch einer VPN-Verbindung zwischen Router und VPN-Gateway):

2017-08-18 10:31:24.806 [WARN ] [.jivesoftware.smack.tcp.PacketWriter] - Exception writing closing stream element
javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Keine Route zum Zielrechner (Read failed)
        at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1551)[:1.8.0_141]
        at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1563)[:1.8.0_141]
        at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:71)[:1.8.0_141]
        at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)[:1.8.0_141]
        at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)[:1.8.0_141]
        at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)[:1.8.0_141]
        at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)[:1.8.0_141]
        at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)[:1.8.0_141]
        at java.io.BufferedWriter.flush(BufferedWriter.java:254)[:1.8.0_141]
        at org.jivesoftware.smack.tcp.PacketWriter.writePackets(PacketWriter.java:190)[185:org.openhab.action.xmpp:1.9.0]
        at org.jivesoftware.smack.tcp.PacketWriter.access$000(PacketWriter.java:40)[185:org.openhab.action.xmpp:1.9.0]
        at org.jivesoftware.smack.tcp.PacketWriter$1.run(PacketWriter.java:77)[185:org.openhab.action.xmpp:1.9.0]
Caused by: javax.net.ssl.SSLException: java.net.SocketException: Keine Route zum Zielrechner (Read failed)
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)[:1.8.0_141]
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1959)[:1.8.0_141]
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1916)[:1.8.0_141]
        at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1880)[:1.8.0_141]
        at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1825)[:1.8.0_141]
        at sun.security.ssl.AppInputStream.read(AppInputStream.java:116)[:1.8.0_141]
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)[:1.8.0_141]
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)[:1.8.0_141]
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)[:1.8.0_141]
        at java.io.InputStreamReader.read(InputStreamReader.java:184)[:1.8.0_141]
        at java.io.BufferedReader.fill(BufferedReader.java:161)[:1.8.0_141]
        at java.io.BufferedReader.read1(BufferedReader.java:212)[:1.8.0_141]
        at java.io.BufferedReader.read(BufferedReader.java:286)[:1.8.0_141]
        at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:2992)[185:org.openhab.action.xmpp:1.9.0]
        at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)[185:org.openhab.action.xmpp:1.9.0]
        at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1144)[185:org.openhab.action.xmpp:1.9.0]
        at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)[185:org.openhab.action.xmpp:1.9.0]
        at org.jivesoftware.smack.tcp.PacketReader.parsePackets(PacketReader.java:291)[185:org.openhab.action.xmpp:1.9.0]
        at org.jivesoftware.smack.tcp.PacketReader.access$000(PacketReader.java:47)[185:org.openhab.action.xmpp:1.9.0]
        at org.jivesoftware.smack.tcp.PacketReader$1.run(PacketReader.java:81)[185:org.openhab.action.xmpp:1.9.0]
Caused by: java.net.SocketException: Keine Route zum Zielrechner (Read failed)
        at java.net.SocketInputStream.socketRead0(Native Method)[:1.8.0_141]
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)[:1.8.0_141]
        at java.net.SocketInputStream.read(SocketInputStream.java:171)[:1.8.0_141]
        at java.net.SocketInputStream.read(SocketInputStream.java:141)[:1.8.0_141]
        at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)[:1.8.0_141]
        at sun.security.ssl.InputRecord.read(InputRecord.java:503)[:1.8.0_141]
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)[:1.8.0_141]
        at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:940)[:1.8.0_141
        at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)[:1.8.0_141]
        ... 14 more

Hinweis: An 'xmpp:securitymode=required' liegt es nicht.


Vielen Dank vorweg schonmal für jede Hilfe.


cu, Lyra

[udo1toni]

Das ist schon bei mehreren Addons/Bindings beobachtet worden, dass es keinen Reconnect gibt. Da man das ja recht leicht verifizieren kann, möchte ich empfehlen einen Issue bei github aufzumachen. Allerdings muss sich dann immer noch jemand finden, der das fixt.

[Lyra]

Vielen Dank für Deine Antwort.

War auf der Suche nach entsprechenden Referenzen bislang noch nicht sehr erfolgreich. Das hier kommt meiner Beobachtung und Deiner Beschreibung bislang am nächsten:
https://github.com/openhab/openhab1-addons/issues/3163

EDIT:
https://github.com/openhab/openhab1-addons/issues/4998

[Lyra]

Habe ein Upgrade von openHAB 2.0 auf 2.1 durchgeführt. Das hat an dem beschriebenen Verhalten nichts geändert.

[udo1toni]

Wie gesagt, das müsste für jedes einzelne Binding, bei dem dieses Verhalten beobachtet wird, gefixt werden.
Z.B. bei knx gibt es extra einen Parameter autoReconnect, rate mal, was der tut...

Melde es als Issue und vielleicht kümmert sich relativ schnell jemand darum. Vergiss aber nicht, dass hier niemand Geld bekommt, entsprechend ist (Engels-)Geduld angesagt.
Ansonsten wäre die unstable Version OH2.2 die, in der dann ein solcher Fix auftaucht. Keine Angst, die ist mindestens so stabil wie 2.1, nur gibt es häufiger Codeänderungen, so dass man eben nicht sicher sein kann, ob man morgen noch den gleichen Code ausgeliefert bekommt, wenn man die Installation an zwei Tagen identisch hochzieht.
Ab und zu kann es passieren, dass die ausgelieferte Version nicht richtig läuft, aber das ist die absolute Ausnahme. Man ist auch nicht gezwungen, täglich Updates einzuspielen, nur weil es täglich eine neue Version gibt solange man mit dem aktuellen Stand zufrieden ist, wartet man auf die nächsten "must have" Features

[Lyra]

Das war erst mal der notwendige Zwischenschritt für ein Issue. So etwas möchte ich nicht mit einer veralteten Version machen, daher zuerst das Upgrade. Hier nur zur Vollständigkeit...

[udo1toni]

Beim Update von 2.1 auf 2.2 musst Du aufpassen. debian bietet beim upgrade an, Konfigurationsdateien beizubehalten (das hängt mit der Arbeitsweise von apt zusammen), das darf man auf keinen Fall so lassen, stattdessen müssen alle Dateien durch die neue Version ersetzt werden. Insbesondere das Logging hat sich so sehr geändert, dass mit der alten Konfigurationsdatei garantiert nichts mehr geloggt wird - falls man hier Änderungen vorgenommen hat, muss man halt nachschauen, wie sich die Befehle geändert haben, und die neue Konfigurationsdatei wieder anpassen. In jedem Fall wird die alte Version aufgehoben (mit Namenserweiterung), so dass man die Unterschiede auch nachträglich noch nachvollziehen kann.