Server Cannot start inMem-objects on port 9001
-
@thomas-braun Ich hatte das auch schon, nur weil ich den iobroker nicht sauber runterfahren konnte, weil sich storage-seitig was weggehängt hat. Stromausfall gibts bei mir normal nicht hab ne USV davor
Das Problem liegt halt eher daran, dass der Prozess gerade in einem Zustand ist, in dem ihn beenden heißt, dass man sich die jsonl zerschießt. Da geht nix mehr außer restore. Evtl. könnte man überlegen das irgendwann mit wechselnden dateien zu machen:- Datei1 und Datei2 sind in sync
- Datei1 wird gelocked
- Datei1 wird geändert
- Detei1 wird sauber geschlossen (-lock)
- Detei2 wird gelocked
- Datei2 wird in Sync gebracht
- Datei2 wird sauber geschlossen (-lock)
So wäre immer eine Datei zum Lesen ohne lock verfügbar und bei solchen Stromausfällen, oder Storage-Problemen wäre ioBroker dann resilient. @Thomas-Braun was meinst Du? Soll/kann ich da irgendwo unterstützen/wollt Ihr sowas da haben?
-
@great-sun Ääääähhhmm ... eine "JSONL" zuerschiessen ... was meinst Du damit genau? "früher" bei den JSON Files der "File DB" konnte das passieren, aber JSONL an sich nicht. Also ws genau ist das Issue um was es hier geht?
-
@apollon77 bei mir kam mal der selbe Fehler, und nachdem alle locks sauber weg waren, war der Syntax in der jsonl nicht mehr korrekt. Es schien, als wäre die Datei nicht komplett sauber auf der Platte gelandet und daher danach unbenutzbar.
-
@great-sun Ok "locks" sind das eine ... Falls da welche bleiben ja dann ist das blöd. Was es das? Sind da "lock files" geblieben?
Ansonsten ist das JSONL Format genau so das selbst einzelne ungültige Einträge egal sind da Sie einfach ignoriert werden. Also was genau was kaputt (was nicht einzelne Datensätze waren)? Die Datei an sich sollte damit aber wie gesagt nicht unbenutzbar werden,
@AlCalzone FYI
-
@apollon77 Ich kanns Dir nicht mehr sagen, hab auch nicht dran gedacht eine Kopie der Datei zu machen... Wenn das nochmal passiert, mach ich das, damit Ihr da vielleicht was debuggen könnt. Mir war das zuviel Stress für zu wenig Nutzen
Und ja, zunächst sah es so aus, als wären es nur die locks. Danach war aber ein File kaputt... ioBroker startete nicht und spuckte immernoch die selbe Fehlermeldung aus iirc. Beim genaueren debuggen bin ich dann auf eine Syntax-Fehlermeldung gestoßen, konnte aber den Fehler nicht finden/beheben. Also Restore und alles ging wieder. -
@great-sun sagte in Server Cannot start inMem-objects on port 9001:
Beim genaueren debuggen bin ich dann auf eine Syntax-Fehlermeldung gestoßen, konnte aber den Fehler nicht finden/beheben. Also Restore und alles ging wieder.
Was für ein syntaxfehler soll das gewesen sein? die JSONL-files sind zeilenweise gültiges JSON. Wenn eine davon kaputt ist, wird sie ignoriert, was aber die Integrität der anderen Dateien nicht beeinflussen dürfte.
Und selbst wenn sie richtig kaputt wäre, kann das nur beim Komprimieren passieren, dann liegt nebendran aber noch ein Backup von vor dem Komprimieren
-
Hi
stoße gerade auf die gleiche Fehlermeldung und blicke so wirklich das Fazit zur Behebung hier nicht.
Habe einen IOB auf einem RPI2 und bestimmt schon 6 Monate nichts verändert nun wollte ich dort mal ran und habe über die Konsole mit IOB stop den IOB beendet und wollte updaten doch hier kommt schon der Fehler:
pi@raspberrypi:~ $ iob update No connection to databases possible ...Um dies zu beheben hab ich mal den Fixer durchlaufen lassen, Neu gebootet und das OS aktualisiert alles ohne erkennbare Fehler aber der IOB startet nicht mehr und der status meldet:
pi@raspberrypi:~ $ iob status Server Cannot start inMem-objects on port 9001: Failed to lock DB file "/opt/iobroker/iobroker-data/objects.jsonl"!Was sollte ich tun?
Besten Dank!
-
@dieter_p
So grundsätzlich bist du da wie genau unterwegs?sudo ln -s /usr/bin/node /usr/bin/nodejs uname -m && which nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejsposten.
-
@thomas-braun said in Server Cannot start inMem-objects on port 9001:
sudo ln -s /usr/bin/node /usr/bin/nodejs
Danke
armv7l /usr/bin/nodejs /usr/bin/node /usr/bin/npm v14.19.3 v14.19.3 6.14.17 pi /home/pi OK:1 http://raspbian.raspberrypi.org/raspbian buster InRelease OK:2 http://archive.raspberrypi.org/debian buster InRelease OK:3 https://deb.nodesource.com/node_14.x buster InRelease Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Alle Pakete sind aktuell. N: Paket nodejssudo kann nicht gefunden werden. N: Paket ln kann nicht gefunden werden. N: Paket /usr/bin/nodejs kann nicht gefunden werden. -
Bitte die komplette Eingabezeile inkl. des login prompts posten.
Da ist irgendwas krumm gelaufen, was ich jetzt nicht nachvollziehen kann, weil ich nicht sehe was da eingeklimpert wurde. (Am Rande: Mit der rechten Maustaste kann man in die Konsole pasten, in den meisten Terminalprogrammen jedenfalls) -
Sorry da stimmte was nicht:
pi@raspberrypi:~ $ uname -m && which nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs sudo ln -s /usr/bin/node /usr/bin/nodejs armv7l /usr/bin/nodejs /usr/bin/node /usr/bin/npm v14.19.3 v14.19.3 6.14.17 pi /home/pi OK:1 http://archive.raspberrypi.org/debian buster InRelease OK:2 http://raspbian.raspberrypi.org/raspbian buster InRelease OK:3 https://deb.nodesource.com/node_14.x buster InRelease Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Alle Pakete sind aktuell. nodejs: Installiert: 14.19.3-deb-1nodesource1 Installationskandidat: 14.19.3-deb-1nodesource1 Versionstabelle: *** 14.19.3-deb-1nodesource1 500 500 https://deb.nodesource.com/node_14.x buster/main armhf Packages 100 /var/lib/dpkg/status 10.24.0~dfsg-1~deb10u1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages sudo: Installiert: 1.8.27-1+deb10u3 Installationskandidat: 1.8.27-1+deb10u3 Versionstabelle: *** 1.8.27-1+deb10u3 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status N: Paket ln kann nicht gefunden werden. N: Paket /usr/bin/nodejs kann nicht gefunden werden. -
@dieter_p sagte in Server Cannot start inMem-objects on port 9001:
Sorry da stimmte was nicht:
Da stimmt immer noch was nicht...
Egal.
cd /opt/iobroker sudo -H -u iobroker npm install iobroker.js-controller -
@thomas-braun said in Server Cannot start inMem-objects on port 9001:
sudo -H -u iobroker npm install iobroker.js-controller
das kommt raus:
pi@raspberrypi:~ $ cd /opt/iobroker pi@raspberrypi:/opt/iobroker $ sudo -H -u iobroker npm install iobroker.js-controller > iobroker.js-controller@4.0.21 preinstall /opt/iobroker/node_modules/iobroker.js-controller > node lib/preinstallCheck.js NPM version: 6.14.17 > iobroker.js-controller@4.0.21 install /opt/iobroker/node_modules/iobroker.js-controller > node iobroker.js setup first No connection to databases possible ... npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@~2.3.2 (node_modules/chokidar/node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.7 (node_modules/osx-temperature-sensor): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/zigbee-herdsman/node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/zigbee-herdsman-converters/node_modules/zigbee-herdsman/node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/zigbee-herdsman-converters/node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"}) npm ERR! code ELIFECYCLE npm ERR! errno 22 npm ERR! iobroker.js-controller@4.0.21 install: `node iobroker.js setup first` npm ERR! Exit status 22 npm ERR! npm ERR! Failed at the iobroker.js-controller@4.0.21 install script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR! A complete log of this run can be found in: npm ERR! /home/iobroker/.npm/_logs/2022-07-07T14_57_18_192Z-debug.log pi@raspberrypi:/opt/iobroker $ -
@dieter_p läuft was anderes auf dem Host auf Port 9000 oder 9001?
-
@apollon77 said in Server Cannot start inMem-objects on port 9001:
@dieter_p läuft was anderes auf dem Host auf Port 9000 oder 9001?
Versuche mal ob ich das heraus bekomme aber wissentlich nein.
Auf dem Pi läuft noch ein WireGuard Client aber der nicht auf 9000/9001 und das auch nicht erst seit gestern sondern schon Monate. Sonst ist nichts installiert.
-
Kannst ja damit mal schauen:
sudo netstat -tulpenWas mich auch wundert:
iobroker.js-controller@4.0.21
Das müsste eigentlich auf allen Kanälen die 4.0.23 sein. Keine Ahnung wo das bei dir herkommt. Vielleicht aus dem npm cache.
-
da scheint nichts zu laufen:
pi@raspberrypi:~ $ netstat -an | grep 9000 pi@raspberrypi:~ $ netstat -an | grep 9001 pi@raspberrypi:~ $ man lsof pi@raspberrypi:~ $ lsof -i:9000 pi@raspberrypi:~ $ lsof -i:9001 pi@raspberrypi:~ $ sudo netstat -tulpen Aktive Internetverbindungen (Nur Server) Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 16710 442/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 14477 287/cupsd tcp6 0 0 :::22 :::* LISTEN 0 16712 442/sshd tcp6 0 0 ::1:631 :::* LISTEN 0 14476 287/cupsd udp 0 0 0.0.0.0:68 0.0.0.0:* 0 16749 364/dhcpcd udp 0 0 0.0.0.0:631 0.0.0.0:* 0 14298 371/cups-browsed udp 0 0 0.0.0.0:36489 0.0.0.0:* 108 14190 298/avahi-daemon: r udp 0 0 0.0.0.0:48820 0.0.0.0:* 0 16853 - udp 0 0 0.0.0.0:5353 0.0.0.0:* 108 14188 298/avahi-daemon: r udp6 0 0 :::48820 :::* 0 16854 - udp6 0 0 :::50885 :::* 108 14191 298/avahi-daemon: r udp6 0 0 :::5353 :::* 108 14189 298/avahi-daemon: r udp6 0 0 :::546 :::* 0 16765 364/dhcpcd pi@raspberrypi:~ $ -
Vermutlich aber eine Desktop-Umgebung am Start.
-
Da Du immer darauf verweist und ich mir bewusst war mit dem RPI2 am Limit zu sein, bin ich mir zu 99,9% sicher nein
Edit:
pi@raspberrypi:~ $ who -r Runlevel 3 2022-07-07 16:20 -
Den cupsd fängt man sich halt bevorzugt mit einem Desktop ein, deswegen komme ich darauf.
npm cache mal gelöscht?
