Test js-controller v2.0.x (GitHub)
-
@Jan1 Ich hätte mindestesn eine Meldung "compact geht nicht daher starte ich normal" erwartet und dann sollte der start direkt erfolgen und ein pot. gestarteter compact sollte sich beenden.
-
@apollon77
so hab noch mal die 0.9.0 drauf und den compact modus aktiviert, jetzt waren plötzlich viele Fehler im Log
War ne blöde Idee noch mal auf 0.9.0 zurück zu gehen, jetzt startet der BLE Adapter nicht mehr. Bin gerade am reparieren.
Läuft wieder nach dem der Fixer drüber ist
-
Ok, sehe schon
alles ok. Ich fixe noch was ... grrrr -
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg den git clone Fehler hatte Arteck auch mal plötzlich. Ursache muss irgendwo bei npm liegen...
Zumindest habe ich ihn jetzt permanent. Ohne "sudo -H..." lässt sich nichts mehr installieren. Die Fehlermeldung seitens npm scheint mir aber auch irreführend. Ich habe ja alle Rechte im tmp-Verzeichnis und spaßeshalber ein chmod 777 darauf bringt keinerlei Besserung. Ev. bringt ja ein neues npm-Release Besserung
-
Auf Systemen, die mit dem neuen Windows Installer eingerichtet wurden, darf der js-controller nicht mir npm aktualisiert werden. Es wird eine neue Version des Windows Installers geben, die das Update des js-controllers mit wenigen Mausklicks ermöglicht. Wir updaten dazu hier im Thread.
[Edit: Defekte Links entfernt. 24.09.19, stabilostick]
-
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Ohne "sudo -H..." lässt sich nichts mehr installieren
Mal den Fixer ausgeführt?
-
@AlCalzone Mehrmals, dürfte aber nix bringen, da NPM meckert, dass er im /[User-Verzeichnis]/.npm/_cacache/tmp/git-clone... das Verzeichnis zum DL nicht anlegen kann. Mit NPM 6.4.1 ging es noch, erst mit dem Update auf 6.11.3 trat es bei mir auf. NPM selbst verriet ja noch, dass es bei älteren Versionen durchaus zu Fehlern in den Userrechten kam. Der vorgeschlagene Fix fruchtet aber auch nicht.
Ist zumindest kein Problem vom Broker/JS-Controller. -
@SBorg Ich sehe üblicherweise die Fehler, dass
npmals non-root ausgeführt wird (wie es sein sollte), aber versucht in/root/.npmzu schreiben. Das kommt meiner Erfahrung nach daher, dass die Rechte im Zielordner falsch sind undnpmdaher auf das falsche Cache-Verzeichnis zugreifen will. -
Danke @apollon77.
Habe das komplette System auf 2.0.7 aktualisiert.
Leider werden die Adapter auch mit dieser Version erst grün, wenn ich die Slave neustarte.
Was mir allerdings gefällt, die Slave Geräte behalten Ihren letzten GPIO (RPI Adapter) Status. (glaube ich ;))Anbei der log vom Slave. iobroker.2019-09-23.log
Neustart Master: 18:45 Uhr
Neustart Slave: 18:52 UhrUnabhängig davon werden mit im log vom Master folgenden warn angezeigt.
admin.2 2019-09-23 18:46:36.260 info (1343) starting. Version 3.6.5 in /opt/iobroker/node_modules/iobroker.admin, node: v10.16.3 Error 2019-09-23 18:46:32.940 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.939 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.936 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.934 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.919 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.917 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.906 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.904 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.900 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.898 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.895 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f host.ioBroker-Rock 2019-09-23 18:46:32.380 info instance system.adapter.admin.2 started with pid 1343 host.ioBroker-Rock 2019-09-23 18:46:32.330 warn Multihost discovery server: service started on 0.0.0.0:50005 -
@e-i-k-e hast du hier mal das volle Master log? Kommen sie auch wenn du Admin neu startest?
-
@SBorg Kannst du mal probieren, den Eigentümer im ioBroker-Ordner zu korrigieren?
sudo chown -R iobroker /opt/iobrokerDas sollte der Fixer eigentlich machen, aber vielleicht stimmt da ja doch was nicht.
-
Anbei das log vom Master.
Könntest du dir bitte auch die Uhrzeit ~1.15 Uhr anschauen. Ich habe seit einigen Tagen Probleme mit meinem ioBroker, dieser hängt sich mehrmals täglich auf. Ich wäre dir sehr dankbar.
Den Admin habe ich nicht neugestartet. Kann ich aber gerne testen.
-
Auf GitHub gibt es jetzt die 2.0.8 . Ich habe nochmal das Stoppen und Restarting angeschaut und überarbeitet.
Ich habe mal mit meinem Redis/Redis Testsystem getestet und einen Redis restart hat es gut weggesteckt@e-i-k-e Kannst bitte das Slave Thema nochnal checken ... bin gespannt auf die Logs. Das "unknown Skript" kann ich mir eher nicht erklären. States und Objects sind "file" oder Objects in Redis?
-
@e-i-k-e Was passiert denn 1:15? Bringt /var/log/syslog irgendwas zu dem Zeitpunkt? Sieht wie ein Reboot aus ... kann RAM kram sein, kann schlechte Stromversorgung sein oder sowas
-
-
Das sieht sehr gut aus, alle Adapter der Slave sind grün
Bei mir sind die Objects in Redis.Anbei das log vom:
Master: iobroker.2019-09-24.log
Slave: iobroker.2019-09-24.logNeustart Master: ~00:07Uhr
Neustart Slave: ~00:14 Uhr -
@e-i-k-e perfekt. Checke es morgen. Jetzt Bett
N8 -
Eigentlich nichts geplantes. Der Absturz passiert auch zu anderen Uhrzeiten.
Anbei mal das syslog, ich selbst kann da nicht viel mit anfangen. syslogN8 und bis morgen.
-
@e-i-k-e sieht alles ok aus. Was war denn da 0:91 los wo wegen „_id of undefined“ die JavaScript Instanz gestorben ist. Passiert das öfter? Ist da ein Script kaputt? Irgendwie reproduzierbar?
-
@e-i-k-e hast du syslog auch von davor? Das 0:17 s geübt für Zeit gewesen zu sein Die Dieuhr hatte beim restart. Würde dann aber auf 6:XX aktualisiert. Daher denke ichbdad der Crash eher da ist.
Um 6:2x macht das System meistens Daily Aufgaben und so und dadurch kann last entstehen.
Was ist für ein Netzteil dran (wird gerade off topic für diesen Thread)
