Monatsrückblick Januar/Februar 2026 ist online!

[Stabilostick]

Das steht in Deinem Logauszug:

See https://github.com/yagop/node-telegram-bot-api/issues/319. at module.js:653:30

Ist doch ganz praktisch, oder?

[derrapf]

Hi
Jetzt sind die "Created issues" weg. Hast du was gemacht?
Ich hab mal den Link aufgerufen aber nur relativ viel Bahnhof verstanden. Vor allem was das für "Versprechen" sind die da in use sind. Muss mich das issue interessieren? Kann das mit dem Absturz des js-controllers zu tun haben?
Gruss Ralf

[derrapf]

Hier hab ich noch was gefunden. Weiss aber nicht ob das ein relevanter Fehler ist:

iot.0	2019-02-25 20:33:57.703	warn	Invalid URL key. Status update is disabled: {"error":"Unsupported version"}
iot.0	2019-02-25 20:33:57.701	error	Cannot report device state: null

Gruss Ralf

[Stabilostick]

@derrapf

Jay-Cee hat den Link in Deinem Log entfernt. Dann verschwinden auch die Boxen. An meinem Beispiel oben siehst Du, auf was die GitHub-Box triggert. Aber jetzt zurück zu Deinem eigentlichen Thema... 🤗

[derrapf]

@Stabilostick
Danke.
Also ich habe jetzt mal die Java-Scripts stillgelegt. Und zwar alle die ich aus dem Netz rauskopiert und eingefügt hatte. Das war einmal eines zum Aufbereiten der IOBroker Logs damit man die in VIS anzeigen kann, und eines das die Anzahl der offenen Fenster zählt bzw. auflistet.
Seit ich das gemacht habe (also vor knapp einer Woche) lief der IOBroker stabil.
Heute hab ich allerdings ein anderes Problem gehabt. Weiss aber nicht ob es da Zusammenhänge gibt: Alle Geräte in der Alexa App waren offline. Auch neu Suchen hat nicht funktioniert. Alles wegwerfen und neu suchen auch nicht. Musste komplett den Skill neu installieren. Sehr seltsam.
Ich hoffe jetzt mal, dass es wirklich nur rein an den Scripten lag. Jetzt schalte ich die mal nacheinander wieder ein. Mal sehen ob er dann wieder instabil wird.
Gruss Ralf

[derrapf]

Inzwischen hat sich der js-controller schon wieder beendet, ohne dass ich eines der Scripten wieder aktiviert hätte. Schade. Daran lag es wohl nicht.
Gibt es irgend eine Möglichkeit das Problem einzugrenzen? Ich sehe im Log nichts auffälliges. Und auch im Syslog nichts.
(also damit meine ich, dass ich als Linux Laie nichts sehe..)

Ich kann die Logs hier einstellen, aber ich müsste wissen welche für Euch interessant sind...
Gruss Ralf

[apollon77]

Erster Anlaufpunkt ist immer das ioBroker Log. Wenn das nichts enthält und sich der ioBroker "einfach so" beednet ist /var/log/syslog der nächste Anlaufpunkt. Dort vor allem nach "oom" ausschau halten - wenn wenn das drin ist war der RAM voll

[derrapf]

@apollon77 sagte in IOBroker hat sich beendet:

Erster Anlaufpunkt ist immer das ioBroker Log. Wenn das nichts enthält und sich der ioBroker "einfach so" beednet ist /var/log/syslog der nächste Anlaufpunkt. Dort vor allem nach "oom" ausschau halten - wenn wenn das drin ist war der RAM voll

Nee "oom" kommt nirgends vor. Ich hab mal die beiden Logs gezippt.

iobroker logs.zip

[apollon77]

Ich denke der schuldige Teil ist der hier:

Mar  4 02:15:14 localhost systemd[2008]: Stopped target Default.
Mar  4 02:15:14 localhost systemd[2008]: Stopped target Basic System.
Mar  4 02:15:14 localhost systemd[2008]: Stopped target Paths.
Mar  4 02:15:14 localhost systemd[2008]: Stopped target Timers.
Mar  4 02:15:14 localhost systemd[2008]: Stopped target Sockets.
Mar  4 02:15:14 localhost systemd[2008]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Mar  4 02:15:14 localhost systemd[2008]: Closed GnuPG cryptographic agent and passphrase cache.
Mar  4 02:15:14 localhost systemd[2008]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Mar  4 02:15:14 localhost systemd[2008]: Closed GnuPG cryptographic agent (access for web browsers).
Mar  4 02:15:14 localhost systemd[2008]: Closed GnuPG network certificate management daemon.
Mar  4 02:15:14 localhost systemd[2008]: Reached target Shutdown.
Mar  4 02:15:14 localhost systemd[2008]: Starting Exit the Session...
Mar  4 02:15:14 localhost systemd[2008]: Received SIGRTMIN+24 from PID 26362 (kill).
Mar  4 02:15:14 localhost systemd[1]: Stopped User Manager for UID 0.
Mar  4 02:15:14 localhost systemd[1]: Removed slice User Slice of root.

Kann es ein das Du ioBroker mal per root manuell per Shell gestartet hast? Aso da wurde der user root quasi final ausgeloggt ... und das hat wohl den ioBroker gekillt.

Was auch immer es war

[derrapf]

@apollon77 sagte in IOBroker hat sich beendet:

Kann es ein das Du ioBroker mal per root manuell per Shell gestartet hast? Aso da wurde der user root quasi final ausgeloggt ... und das hat wohl den ioBroker gekillt.
Was auch immer es war

Ich verstehe nicht ganz was du genau meinst.
Ja, ich logge mich bisher immer mit root auf dem Rock64 ein. Einen anderen User gibt es da nicht.
Und Iobroker habe ich immer als root manuell gestartet, weil der automatische Start bis gestern nicht ging.

Was war da jetzt genau falsch dran?

Gruss Ralf

[apollon77]

ich sage nicht das da etwas "falsch" ist, fakt ist das 2:15 Uhr wo dein problem war genau im syslog zu sehen war das alle root-Prozesse gekillt wurden ... und das ist scheinbar Dein Problem irgendwie. So tief bin ich jetzt auch nicht fit in Linux und kann daher auch nur versuchen logs zu deuten.

Jetzt mit Autostart sollte es ggf besser sein. Also beobachte es mal weiter.

[derrapf]

@apollon77
Hi Apollon77
Hmm... Ich bin zwar oft lang wach, aber explizit root prozesse habe ich nicht gekillt. IObroker fahre ich immer gesittet runter. Und zu dem Zeitpunkt als er ausgstiegen ist hab ich ziemlich sicher nachts nicht rumgedoktert.

.. Halt. Idee:
Ich habe einen Cron-Job laufen der nachts ein Backup macht. Augeblick, ich gucke....
...

Kann es sein, dass ein Script zum Backuppen der SD-Karte hier vielleicht Ärger macht? Das wird um 2:15 Montags gestartet. Und der 4.März war ja ein Montag!
Das sieht (noch aus Raspberry Zeiten) so aus:

cd /opt/iobroker
sudo iobroker stop
sudo dd if=/dev/mmcblk0 of=/mnt/nas/backup/rock64_backup$NOW.img
sudo iobroker start

[apollon77]

Ich bin mir nicht sicher ob dd ohne "unmound" des Dateisystems gehen kann ... wenn das so wäre dann ist es für mich auch erklärt :-)

[derrapf]

@apollon77
Hi
Ich kann aber das Dateisystem ja nicht unmounten. Schon gar nicht /mnt/nas weil das ist das Synology NAS auf das das Backup geht.
Funktionieren tut irgendwas, denn da liegen lauter 32GB grosse *.img Dateien rum.

Und ich fahre doch den IOBroker vorher runter und danach wieder hoch. Da dürfte doch nichts passieren, oder?

Gruss Ralf

[Mapio90]

Hallo , ich habe dass problem dass ich seit dem stromausfall nicht mehr auf die weboberfläche komme und sich somit der iobroker verabschiedet hat?

iobroker läuft auf einem Raspberry 3b+
node -v = v10.15.3
npm -v = 6.4.1

wenn ich den befehl eingebe iobroker status , kommt folgendes:

root@ioBroker-RasPi:/home/pi# iobroker status
internal/modules/cjs/loader.js:584
throw err;
^

Error: Cannot find module '/opt/iobroker/node_modules/iobroker.js-controller/iobroker.js'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:582:15)
at Function.Module._load (internal/modules/cjs/loader.js:508:25)
at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

[apollon77]

Ist das File denn da? Nicht das es Deine SD Karte oder das Dateisystem zerstört hat beim Stromausfall

[Mapio90]

welches file meinst du?

[apollon77]

@Malo_60 sagte in IOBroker hat sich beendet:

Error: Cannot find module '/opt/iobroker/node_modules/iobroker.js-controller/iobroker.js'

[Mapio90]

ich habe schon ein backup auf eine andere sd karte gespielt, geht auch nicht.

[Homoran]

@Malo_60
Bitte such mal den von @apollon77 angegebenen Pfad:
/opt/iobroker/node_modules/iobroker.js-controller/

und prüfe ob sich die angemeckerte Datei
iobroker.js
dort befindet