Nachdem ich bis jetzt noch nicht viele Adapter genutzt habe, habe ich iobroker neu installiert. Mal schauen ob das Problem wieder auftaucht.

Ergänzende Info, vielleicht hilft das noch zusätzlich, wenn ich systemctl status iobroker aufrufe, dann kommt:

systemctl status iobroker
● iobroker.service - ioBroker Server
     Loaded: loaded (/lib/systemd/system/iobroker.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Thu 2022-12-01 14:16:54 CET; 2s ago
       Docs: http://iobroker.net
    Process: 4045592 ExecStart=/bin/bash -c ${NODE} /opt/iobroker/node_modules/iobroker.js-controller/controller.js (code=exited, status=217/USER)
   Main PID: 4045592 (code=exited, status=217/USER)
        CPU: 2ms

Dez 01 14:16:58 idefix systemd[4045598]: iobroker.service: Failed at step USER spawning /bin/bash: No such process
Dez 01 14:16:58 idefix systemd[1]: iobroker.service: Main process exited, code=exited, status=217/USER
Dez 01 14:16:58 idefix systemd[1]: iobroker.service: Failed with result 'exit-code'.
Dez 01 14:17:01 idefix systemd[1]: iobroker.service: Scheduled restart job, restart counter is at 4589.
Dez 01 14:17:01 idefix systemd[1]: Stopped ioBroker Server.
Dez 01 14:17:01 idefix systemd[1]: Started ioBroker Server.
Dez 01 14:17:01 idefix systemd[4045603]: iobroker.service: Failed to determine user credentials: No such process
Dez 01 14:17:01 idefix systemd[4045603]: iobroker.service: Failed at step USER spawning /bin/bash: No such process
Dez 01 14:17:01 idefix systemd[1]: iobroker.service: Main process exited, code=exited, status=217/USER
Dez 01 14:17:01 idefix systemd[1]: iobroker.service: Failed with result 'exit-code'.

@crunchip said in Iobroker startet nicht mehr - cannot read system.config:

https://forum.iobroker.net/topic/43325/mini-howto-cannot-find-view-system-for-search-host?_=1629541630785

Danke für den Hinweis, dorthin hat mich auch google geführt. Allerdings ist mein /backup-objects/ Verzeichnis leer.

@thomas-braun
Naja - nach dem Stoppen des iobroker, war auch tmp wieder in Ordnung.
Aktuell:

df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            941M       0  941M    0% /dev
tmpfs           192M    3,5M  189M    2% /run
/dev/sda1       910G     42G  822G    5% /
tmpfs           958M       0  958M    0% /dev/shm
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           958M    1,1M  957M    1% /tmp
/dev/md0        7,3T    3,1T  4,2T   42% /media/2cd13aec-23e9-4a82-8805-07d1c909e664
tmpfs           192M    8,0K  192M    1% /run/user/1000

Hallo,

nachdem ich mit eurer Hilfe den IOBroker zum Laufen gebracht habe, lief dieser bis heute auch problemlos. Über das Web-Interface habe ich heute gesehen, dass es Fehlermeldungen im Log gibt.
Es fanden sich mehrere Einträge mit:

2022-12-01 07:37:45.464  - error: host.idefix-Server Cannot save backup /opt/iobroker/iobroker-data/backup-objects/2022-12-01_07-37_objects.jsonl.gz: ENOSPC: no space left on device, write
2022-12-01 09:28:09.106  - warn: mielecloudservice.0 (3753727) An undefined error occurred. Handling it in 1.563 seconds to give it a chance to solve itself.
2022-12-01 09:28:10.688  - info: mielecloudservice.0 (3753727) SSE is trying to reconnect but it seems this won't work. So trying myself by closing and reinitializing.
2022-12-01 09:37:13.184  - info: mielecloudservice.0 (3753727) Watchdog detected ping failure. Last ping occurred over a minute ago. Trying to handle.
2022-12-01 09:37:13.288  - info: mielecloudservice.0 (3753727) Server Sent Events-Connection has been established @Miele-API.

Ein check mittels df zeigte, dass /tmp/ zu 100% voll war, alle anderen Partitionen hatten noch Platz. Mittels lsof +D /tmp geprüft, welche Prozesse noch aktiv auf /tmp/ files halten:

lsof +D /tmp
COMMAND       PID     USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
iobroker.     875 iobroker  381u   REG   0,33  1069056 726166 /tmp/2022-11-18_21-37_objects.jsonl
iobroker.     875 iobroker  382u   REG   0,33        0 728360 /tmp/2022-11-18_23-37_objects.jsonl
iobroker.     875 iobroker  383u   REG   0,33        0 729391 /tmp/2022-11-19_01-37_objects.jsonl
iobroker.     875 iobroker  384u   REG   0,33        0 730143 /tmp/2022-11-19_03-37_objects.jsonl
iobroker.     875 iobroker  385u   REG   0,33        0 730897 /tmp/2022-11-19_05-37_objects.jsonl
iobroker.     875 iobroker  386u   REG   0,33        0 731689 /tmp/2022-11-19_07-37_objects.jsonl
iobroker.     875 iobroker  387u   REG   0,33        0 732444 /tmp/2022-11-19_09-37_objects.jsonl
iobroker.     875 iobroker  388u   REG   0,33        0 733199 /tmp/2022-11-19_11-37_objects.jsonl
iobroker.     875 iobroker  389u   REG   0,33        0 733954 /tmp/2022-11-19_13-37_objects.jsonl
iobroker.     875 iobroker  390u   REG   0,33        0 734708 /tmp/2022-11-19_15-37_objects.jsonl
iobroker.     875 iobroker  391u   REG   0,33        0 735464 /tmp/2022-11-19_17-37_objects.jsonl
iobroker.     875 iobroker  392u   REG   0,33        0 736219 /tmp/2022-11-19_19-37_objects.jsonl
iobroker.     875 iobroker  393u   REG   0,33        0 736973 /tmp/2022-11-19_21-37_objects.jsonl

Das ist nur ein kurzer Auszug, die Liste hat mehrere Bildschirmseiten gefüllt. Also irgendwas lag da mit ioBroker im argen. Daraufhin habe ich mittels iobroker stop den iobroker gestoppt. Das hat relativ lange gedauert, ging aber durch.
Danach lies sich der iobroker nicht mehr starten:

iobroker status
 Cannot read system.config: null (OK when migrating or restoring)
iobroker is not running on this host.


Objects type: jsonl
States  type: jsonl

Und ab da stehe ich als Neuling jetzt leider ein wenig auf der Leitung. Ich vermute mal der Fehler mit dem /tmp/ hat dazu geführt, dass irgendwas an der config jetzt kaputt ist. Wie am besten weitermachen?

Danke für eure Hilfe,
Gernot

@thomas-braun
Also bei mir hab ich folgendes Szenario:

• Ich arbeite alleine auf dem System (d.h. root passwort wird nicht geteilt)
• Root login über ssh ist gesperrt
• Ich logge mich mit meinem user ein und wenn ich etwas an der Konfiguration ändern will, mache ich eine session mittels su - auf.
• Bin ich mit den Konfigurationsänderungen fertig, beende ich die session mittels exit

Ich hab in dem Szenario noch nicht ganz verstanden, welchen Sicherheitsvorteil sudo bringen sollte, lass mich aber auch gerne eines besseren belehren.
Vielleicht liegt es auch einfach daran, dass meine ersten Linuxerfahrungen aus einer Zeit stammen, wo:

• das Internet noch in den Kinderschuhen steckte
• die bekannteste Linux Distro slackware war
• man sich die Distro auf der UNI mittels 5 1/4 Zoll Disketten kopierte, weil ein Internetanschluß mittels Modem für einen Studenten einfach viel zu teuer war

lg
Gernot

@thomas-braun said in iobroker startet nach Erstinstallation nicht:

uname -m && type -P nodejs node npm && nodejs -v && node -v && npm -v && iob -v && whoami && groups && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs

root@idefix:~/test/download# uname -m && type -P nodejs node npm && nodejs -v && node -v && npm -v && iob -v && whoami && groups && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs
x86_64
/usr/bin/nodejs
/usr/bin/node
/usr/bin/npm
v16.18.0
v16.18.0
8.19.2
4.0.23
root
root
/root/test/download
OK:1 http://deb.debian.org/debian bullseye InRelease
OK:2 http://as-repository.openvpn.net/as/debian bullseye InRelease                                    
OK:3 http://deb.debian.org/debian-security bullseye-security InRelease                                
OK:4 https://deb.nodesource.com/node_16.x bullseye InRelease                  
OK:5 http://deb.debian.org/debian bullseye-updates InRelease
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Alle Pakete sind aktuell.
nodejs:
  Installiert:           16.18.0-deb-1nodesource1
  Installationskandidat: 16.18.0-deb-1nodesource1
  Versionstabelle:
 *** 16.18.0-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_16.x bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
     12.22.12~dfsg-1~deb11u1 500
        500 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages
     12.22.5~dfsg-2~11u1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages

@thomas-braun

Danke für eure Hilfe, auch wenn es eigentlich nix mit iobroker zu tun hatte.

@thomas-braun

So ich habe jetzt die package nodejs deinstalliert, dann sources.list bereinigt und auf bullseye gestellt. Dann mittels:

apt list --installed | grep lokal >& unstable_packages.log

die packages ermittelt, von denen neuere / unstable versionen installiert wurden. Mittels bash script aus der Liste die stable Pakete über:

apt download package/stable

geholt und mit

dpgk -i *.deb

alle installiert (also eigentlich ein downgrade gemacht).
Dann noch ein:

apt --fix-broken install
apt-get update
apt-get dist-upgrade

hinterher.

Damit sollte das System hoffentlich wieder auf stable unterwegs sein. Kann ich jetzt einfach die iobroker installation löschen (also das /opt/iobroker Verzeichnis) und dann das Installationsskript nochmals ausführen? Dann sollte ja auch die korrekte nodejs version installiert werden.

@homoran said in iobroker startet nach Erstinstallation nicht:

@gernot-lepuschitz sagte in iobroker startet nach Erstinstallation nicht:

Der Fehler mit wireguard ist mir passiert (offensichtlich schon vor einem Jahr).

shit happens!
kann jedem passieren, aber bookworm vor einem Jahr???

Nein - aber der unstable / main Eintrag der in weiterer Folge dann zu bookworm / sid geführt hat.

@gernot-lepuschitz sagte in iobroker startet nach Erstinstallation nicht:

wäre es wohl das einfachste, den unstable Eintrag zu entfernen und in den anderen sources buster durch bookworm zu ersetzen.

nein, durch bullseye

Sicher? Würden dann auch neuere Versionen wieder durch ältere aus Bullseye ersetzt werden?