UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[liv-in-sky]

@arteck
es ist meine art herauszufinden, was das problem ist - läuft rebuild durch ohne fehler könnte man das mal ausschliessen. ein rebuild tut nicht weh und zeigt das auf dieser ebene alles ok ist.

wenn du schon vermutungen anstellst, dann zeige auch auf wie man die sd-karte prüft oder soll er gleich eine neue kaufen ?

wo habe ich geschrieben er soll iobroker neuinstallieren - wo habe ich geschrieben er soll was neues kaufen - spar dir deine übertreibungen - diese sind völlig überflüssigf und muss es sein dass du mich gleich einne "irren" nennst ?

[AlCalzone]

@liv-in-sky Ein rebuild aller nativen Module ist absolut unnötig, wenn im Log nichts steht von wegen "compiled against a different node version". Das ist wie im Auto erst mal das Getriebe ausbauen, wenn der Schrittmotor für die Sitzverstellung hakt.

Um sinnvolle Vorschläge machen zu können, benötige ich zumindest mal einen Log anhand dessen man den Fehler ansatzweise nachvollziehen kann. Skripte deaktivieren, beobachten und schrittweise wieder aktivieren ist auf jeden Fall schon mal ein vernünftiger Ansatz.

[liv-in-sky]

@AlCalzone - leider habe ich andere erfahrungen gemacht - bei meinem letzten admin update kam ""compiled against a different node version"" nicht - und trotzdem war eine reparatur nur über rebuild möglich - ich mußte den admin downgraden - einen rebuild machen und danach könnte ich den admin wieder updaten

bitte um letzte aufklärung:

ein rebuild muss immer und jederzeit funktionieren - ich gehe davon aus (kann auch falsch sein) das nur ein adapter programmierer vergessen hat, bestimmte fehler abzufragen (z.b. rechte auf etwas) - und dann genau das passiert -man hat keine richtigen eintragungen im log und es kommt zu eigenartigen fehlern - ich habe das log angeschaut und nichts gefunden (außer evt. script problem oder ein adapterproblem ,
vom system sicht her, mag es schon sein, dass es etwas groß ist, einen rebuild auszuführen - wenn ich aber einige threads anschaue stellen sich häufig fehler dar, wo es um rechte geht und die werden im rebuild sehr gut sichtbar.
der rebuild ist von user sicht relativ einfach - eine tiefe linux diagnose hingegen nur für linux profis - sd kartenfehler findest du mit glück im linux log - nicht im iobroker log. einen sdkartenfehler zufinden ohne linux analyse - wie sollte das funktionieren ?

wenn schon solche vergleiche gezogen werden müssen - eine sd karte zu tauschen ist wie das getriebe zu wechseln - ein rebuil ist wie das anschließen eines diagnosegerätes - wenn keine fehler, dann wird weiter händisch im motorraum getestet -

ich gebe euch beiden recht , wenn ihr mir den tatsächlichen nachteil eines rebuilds darlegen könnt -ist er erfolgreich sind grundsätzliche fehler ausgeschlossen - ist er nicht erfolgreich, gibt er fehler aus, die vielleicht weiterhelfen - wo ist da mein denkfehler ?

[arteck]

@liv-in-sky sagte in NAch Update Host und Admin tägliche Abstürze:

ich gebe euch beiden recht , wenn ihr mir den tatsächlichen nachteil eines rebuilds darlegen könnt -ist er erfolgreich sind grundsätzliche fehler ausgeschlossen - ist er nicht erfolgreich, gibt er fehler aus, die vielleicht weiterhelfen - wo ist da mein denkfehler ?

wenn die sd karte fratze ist bekommst du bei einem rebuild die Fehler immer an andere stele. wie willst du da was lokalisieren.. ohne LOG..

aber du scheinst ja mehr Ahnung zu haben als die 2 die Adapter Entwicklung betreiben.. ich bin raus hier...

[liv-in-sky]

@arteck

zuerst die leute als irre bezeichnen und dann den user im stich lassen - wenn der rebuild solche undefinierten fehler macht wäre es genau der hinweis, dass die karte defekt ist - damit ist das problem lokalisiert und auch bestätigt das es iobroker selbst nicht ist - man kann neben dem rebuild noch das syslog mit tail ansehen und alles ist gut

das ist doch das, was ich rausfinden wollte

[AlCalzone]

@liv-in-sky sagte in NAch Update Host und Admin tägliche Abstürze:

leider habe ich andere erfahrungen gemacht - bei meinem letzten admin update kam ""compiled against a different node version"" nicht - und trotzdem war eine reparatur nur über rebuild möglich

Dann war das ein Nebeneffekt des Downgrades oder ein Paket, was dabei neu installiert wurde, wahrscheinlich hätte es ein npm install im richtigen Ordner getan.
Siehe auch die Dokumentation des Befehls:

This command runs the npm build command on the matched folders. This is useful when you install a new version of node, and must recompile all your C++ addons with the new binary.

Glaube es mir oder nicht - npm rebuild als Troubleshooting ist Unsinn. Wenn das nötig ist, äußert es sich laut und deutlich in Rot im Log. Zum Korrigieren von Rechten haben wir den Fixer

@liv-in-sky sagte in NAch Update Host und Admin tägliche Abstürze:

ein rebuil ist wie das anschließen eines diagnosegerätes - wenn keine fehler, dann wird weiter händisch im motorraum getestet -

Und da liegst du falsch. Um bei der Metapher zu bleiben, es ist wie das Ausbauen aller bewegten Komponenten, um deren Lager zu prüfen und ggf. zu tauschen. Du kannst es gerne weiterhin bei deinen Problemen machen, im Regelfall (ohne die genannte Fehlermeldung) ist es aber Zeitverschwendung.

Zurück zum Thema: Reconnecting to DB ist für mich immer noch eine Überlastung des Systems - hier sollte man ansetzen.

[liv-in-sky]

@AlCalzone

danke dir für die ausführliche und freundliche antwort - werde das ab jetzt berücksichtigen

• ein "falsches" script sollte auf jeden fall gefunden werden - falls existent und ursache der überlastung - ansonsten wird das problem auf den neuen raspi 4 mit übernommen

[chemieka]

Das tut mir jetzt leid hier für Diskussionen gesorgt zu haben.
Nach dem Update von den Java Adapter auf 4.1.13 ist es erst einmal ruhig geworden. Kann nur hoffen es bleibt so.

Ihr seit mir jetzt nicht so böse wenn ich mal keine Ahnung habe wovon ihr geschrieben habt. 🥴

Ich würde aber auch an einen Fehler der Karte denke. Eine Neue ist unterwegs.

Melde mich wenn die Fehler wieder kommen.

[liv-in-sky]

@chemieka

nee sorry von mir - war dein thread , da sollte das nicht vorkommen - hat sich alles beruhigt

[chemieka]

Alles gut. Auch heute läuft das System noch ruhig. Eventuell lag es doch an der Java Version in Verbindung mit meinen Skripten.

[chemieka]

Problem doch nicht gelöst. VIS läuft noch aber das Web Interface läuft nicht mehr.
Könnte jetzt mal schauen welcher Adapter nicht läuft bevor ich ein Reboot mache.
Soll ich noch nach was anderen schauen?

[chemieka]

pi@ioBroker-RasPi:~ $ iobroker list instances
  system.adapter.admin.0                 : admin       -  enabled, port: 8081, bind: 0.0.0.0, run as: admin
+ system.adapter.alexa2.0                : alexa2      -  enabled
+ system.adapter.backitup.0              : backitup    -  enabled
+ system.adapter.cloud.0                 : cloud       -  enabled
  system.adapter.dwd.0                   : dwd         -  enabled
  system.adapter.flot.0                  : flot        -  enabled
+ system.adapter.fritzbox.0              : fritzbox    -  enabled
+ system.adapter.harmony.0               : harmony     -  enabled
+ system.adapter.history.0               : history     -  enabled
+ system.adapter.hm-rega.0               : hm-rega     -  enabled
+ system.adapter.hm-rpc.0                : hm-rpc      -  enabled, port: 0
+ system.adapter.hue.0                   : hue         -  enabled, port: 80
  system.adapter.ical.0                  : ical        -  enabled
+ system.adapter.javascript.0            : javascript  -  enabled
+ system.adapter.javascript.1            : javascript  -  enabled
+ system.adapter.pushover.0              : pushover    -  enabled
  system.adapter.rickshaw.0              : rickshaw    -  enabled
+ system.adapter.scenes.0                : scenes      -  enabled
+ system.adapter.simple-api.0            : simple-api  -  enabled, port: 8087, bind: 0.0.0.0, run as: admin
+ system.adapter.smartmeter.0            : smartmeter  -  enabled
+ system.adapter.smartmeter.1            : smartmeter  -  enabled
+ system.adapter.socketio.0              : socketio    -  enabled, port: 8084, bind: 0.0.0.0, run as: admin
+ system.adapter.spotify-premium.0       : spotify-premium -  enabled
+ system.adapter.tr-064-community.0      : tr-064-community -  enabled
  system.adapter.vis-colorpicker.0       : vis-colorpicker -  enabled
  system.adapter.vis-history.0           : vis-history -  enabled
  system.adapter.vis-players.0           : vis-players -  enabled
  system.adapter.vis.0                   : vis         -  enabled
+ system.adapter.web.0                   : web         -  enabled, port: 8082, bind: 0.0.0.0, run as: admin

+ instance is alive

Erstmal nicht ungewöhnlich!?

[liv-in-sky]

@chemieka

• definitiv interesant wäre das ganze log file von /opt/iobroker/log vom heutigen tag
• auch ein auszug aus dem syslog könnte einblick geben
  dies ist der befehl - erzeugt ein file mit namen "syslog.heute.log"

cat /var/log/syslog | grep "Jul  4"  >syslog.heute.log

die beiden dateien als txt file im forum posten (die datei direkt in das forum ziehen)

[chemieka]

das Systemlog:syslog.txt

Da steht schon mal was mit Kill Prozess wegen Speicherplatz.

[chemieka]

Und der Log

iobroker.2019-07-04.log

[liv-in-sky]

@chemieka

du könntest mal ein swap-file einrichten - bis deine neuen geräte kommen kann man auch mal etwas swappen - dann hast du ja wieder mehr speicher

[liv-in-sky]

@chemieka

soweit ich das kapiere läuft dieses script kurz vorher an - ob das zusammenhängt weiß ich nicht

javascript.0 script.js.Skript1:

du könntest auch das erstmal beenden und abwarten

im iobroker log sieht man den SIGKILL - dass schießt den iobroker vom system her ab

[chemieka]

das mit dem Swapen kommt mir bekannt vor, denke das habe ich gemacht schaue aber noch mal. Die Skripte laufen dauernd und eigentlich auch als einziges, denke daran liegts nicht nur dort wällt es erst auf. Wäre auch unklar weil vor dem Update gab es da keine Probleme.

[liv-in-sky]

@chemieka

swap:
https://www.elektronik-kompendium.de/sites/raspberry-pi/2002131.htm

weiß auch nicht, wie das zusammenhängen kann - deine entscheidung - swap ein oder script aus und abwarten für einen tag

vielleicht benötigen die updates etwas mehr speicher und du warst bis jetzt immer an der grenze - danach bumm !

du könntest auch wieder einen downgrade der updates fahren - aber das glaube ich führt nicht zum ziel, weil irgendwann muss update eh passieren

poste doch mal das script - vielleicht findet sich ein profi, der das analysieren kann

[chemieka]

Also ich muss mal sagen da läuft nun nix besonderes an Adaptern und nun auch nicht so viel das da der RAM wieder nicht reichen soll ist schon blöd. Ich würde mal zum Test die Karte kopieren und auf eine andere Karte laden ob das einen Unterschied macht. Man muss ja sagen, dass vor dem Update das System mind. 6 Monate ohne Fehler lief.