instance system.adapter.luftdaten.1 already running

[ratte-rizzo]

@homoran sagte in instance system.adapter.luftdaten.1 already running:

So eine Meldung kommt nach einem Neustart des Adapters ohne dass er vorher richtig beendet wurde.

Und woran kann das liegen? Tagelang funktioniert er brav und dann hängt er sich auf. Dann schieße ich ihn mit "kill" ab und dann gehts wieder tagelang gut.

[Homoran]

@ratte-rizzo sagte in instance system.adapter.luftdaten.1 already running:

Und woran kann das liegen?

Update des Adapters - kommt wohl nicht so häufig vor
herunterfahren, restart o.ä., vielleicht auch Konfig-Änderungen, nach denen die Instanz neu gestartet wird nd evtl. vorher nicht sauber gestoppt wurde.

Das kann womöglich bei zu hoher Load average passieren

[UncleSam]

@homoran sagte in instance system.adapter.luftdaten.1 already running:

beendet sich trotz timeout korrekt

Ich möchte dem (ein Bisschen) widersprechen:

2021-01-18 21:30:00.017 - info: host.himbeere instance system.adapter.luftdaten.1 started with pid 3708
2021-01-18 21:30:04.032 - info: host.himbeere instance system.adapter.luftdaten.0 started with pid 3733
2021-01-18 21:30:15.715 - info: host.himbeere instance system.adapter.luftdaten.0 terminated with code 0 (NO_ERROR)
2021-01-18 21:32:11.045 - error: luftdaten.1 (3708) connect ETIMEDOUT 192.168.178.113:80
2021-01-18 21:32:21.556 - info: host.himbeere instance system.adapter.luftdaten.1 terminated with code 0 (NO_ERROR)
2021-01-18 21:35:00.017 - info: host.himbeere instance system.adapter.luftdaten.0 started with pid 8461
2021-01-18 21:35:04.034 - info: host.himbeere instance system.adapter.luftdaten.1 started with pid 8476
2021-01-18 21:35:11.849 - info: host.himbeere instance system.adapter.luftdaten.0 terminated with code 0 (NO_ERROR)
2021-01-18 21:40:00.002 - warn: host.himbeere instance system.adapter.luftdaten.1 already running with pid 8476

Instanz 0 hat nie ein Timeout und trotzdem startet sie regelmässig neu (mit etwa 5 Sekunden Versatz zu Instanz 1).

[ratte-rizzo]

@unclesam sagte in instance system.adapter.luftdaten.1 already running:

Instanz 0 hat nie ein Timeout und trotzdem startet sie regelmässig neu (mit etwa 5 Sekunden Versatz zu Instanz 1).

Das ist korrekt. Instanz 0 hat sich noch nie aufgehängt. Allerdings gibts da auch nie Timeouts (falls das damit etwas zu tun haben sollte).

[UncleSam]

@ratte-rizzo OK, jetzt verstehe ich. Das ist ein Adapter, der kurz startet, die Daten holt und sich dann wieder beendet.

Das heisst, beim Gerät, das du mit der Instanz 1 ansprichst, kommt es zu Verbindungsproblemen. WLAN?

Und dann gibt es möglicherweise ein Problem im Adapter: die Instanz 1 läuft immer noch (da sie wohl kein Timeout hat, aber sonst irgendwie hängt) und damit kann sie kein zweites Mal gestartet werden.

Ich würde mal die Verbindung zu 192.168.178.113 pingen (ping -t 192.168.178.113) und schauen, ob du die Verbindungsprobleme auch hast.

[Homoran]

@unclesam sagte in instance system.adapter.luftdaten.1 already running:

Instanz 0 hat nie ein Timeout und trotzdem startet sie regelmässig neu (mit etwa 5 Sekunden Versatz zu Instanz 1).

OOps - das sind zwei Instanzen

[Homoran]

@unclesam sagte in instance system.adapter.luftdaten.1 already running:

Das ist ein Adapter, der kurz startet, die Daten holt und sich dann wieder beendet.

korrekt, das ist ein Adapter mit scheduled Instanzen.
Der Server von Luftdaten.info hat aber immer wieder Aussetzer.

Ich habe auch zwei Instanzen, mit denen ich zwei Stationen abfrage.
Eine davon ist immer wieder bei Luftdaten.info offline (kann man dann auch auf deren Website sehen) und dann kommt es zu dem timeout Daten auszulesen, die nicht da sind

[ratte-rizzo]

@Homoran
Ja, 2 Instanzen Tschuldigung, hätte ich vielleicht nochmal betonen sollen.

@UncleSam
Ja, die Verbindung ist manchmal schlecht, weil der Sensor relativ weit weg ist von der FritzBox. Daher kann es manchmal halt zu Aussetzern kommen. Ich habe halt die Vermutung (hab davon halt keine Ahnung), dass der Adapter mit den Timeouts nicht so 100%ig zurecht kommt.

Es sind aber in diesem Falle 2 Sensoren bei mir, die Daten werden ja auch über lokale IP Adressen abgefragt und nicht über den Server von luftdaten.info

[Homoran]

@ratte-rizzo sagte in instance system.adapter.luftdaten.1 already running:

die Daten werden ja auch über lokale IP Adressen abgefragt

geht das?

dann würde ich da auf jeden fall mal testen ob der Sensor erreichbar ist.
Aber dass das snn zu einem "nicht beenden" der Instanz führt kenne ich nicht

[ratte-rizzo]

@homoran sagte in instance system.adapter.luftdaten.1 already running:

@ratte-rizzo sagte in instance system.adapter.luftdaten.1 already running:

die Daten werden ja auch über lokale IP Adressen abgefragt

geht das?

Jup, das geht, wenn man einen Sensor selber betreibt, dann kann man den auch direkt abfragen.

dann würde ich da auf jeden fall mal testen ob der Sensor erreichbar ist.
Aber dass das snn zu einem "nicht beenden" der Instanz führt kenne ich nicht

Naja, "meistens" ist er ja erreichbar. Ich kann Sensor und FritzBox leider nicht dichter zusammen bringen, bzw. keinen Repeater dazwischen setzen. Vielleicht sollte ich das bei GitHub als Issue posten, dass der Entwickler des Adapters da nochmal drüber schaut?

[UncleSam]

@ratte-rizzo sagte in instance system.adapter.luftdaten.1 already running:

Ich habe halt die Vermutung (hab davon halt keine Ahnung), dass der Adapter mit den Timeouts nicht so 100%ig zurecht kommt.

Ja, habe ich auch das Gefühl. Ich würde mal ein Issue auf GitHub eröffnen und auf dieses Thema hier verweisen. Der Adapter bleibt nämlich teilweise länger als 5 Minuten hängen und dann kann der nächste Schedule nicht ausgeführt werden.

[Homoran]

@unclesam sagte in instance system.adapter.luftdaten.1 already running:

Der Adapter bleibt nämlich teilweise länger als 5 Minuten hängen und dann kann der nächste Schedule nicht ausgeführt werden.

das würde dann heißen dass der nächste schedule wohl startet, aber der andere nochnicht beendet wurde

[UncleSam]

@homoran sagte in instance system.adapter.luftdaten.1 already running:

das würde dann heißen dass der nächste schedule wohl startet, aber der andere nochnicht beendet wurde

Ja, genau das wollte ich sagen...