Iobroker nicht mehr erreichbar / Festplatte voll?

[Thomas Braun]

@erazor86

echo "" | sudo tee /var/log/kern.log

sollte das kern.log löschen. Analog

echo "" | sudo tee /var/log/syslog

[erazor86]

@thomas-braun said in Iobroker nicht mehr erreichbar / Festplatte voll?:

@erazor86

echo "" | sudo tee /var/log/kern.log

sollte das kern.log löschen. Analog

echo "" | sudo tee /var/log/syslog

super! danke euch beiden

pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        55G  5.1G   48G  10% /
devtmpfs        1.8G     0  1.8G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G   17M  1.9G   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sda1       253M   49M  204M  20% /boot
tmpfs           384M     0  384M   0% /run/user/1000

jetzt habe ich erstmal was Zeit gewonnen und kann mal was essen

[A Former User]

@erazor86 sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:

sudo systemctl status

Moin,

nach dem status muss natürlich auch das eingetragen werden, was bei lsof angezeigt wird.
Bei mir z. B. promtail, ist nur ein Dienst bei mir

# lsof /var/log/kern.log
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
rsyslogd 1503     root   12w   REG  253,1    33738 50334529 /var/log/kern.log
promtail 2879 promtail   25r   REG  253,1    33738 50334529 /var/log/kern.log

Wenn bei dir da nichts kommt, dann muss man auch nichts stoppen, und kann gleich zum Löschen übergehen, die Methode von @Thomas-Braun geht auch, solange da keiner einen Filehandle drauf hat, mitunter, zieht man damit einem Programm den Stuhl unter dem Arsch weg, führt aber hier und jetzt zuweit.
Gut, dass es jetzt erst einmal wieder aufgeräumt aussieht.
Du solltest aber schauen, ob Log Rotate läuft

dp20eic@iobroker:~$ systemctl status logrotate.timer 
* logrotate.timer - Daily rotation of log files
     Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2023-10-17 09:21:40 CEST; 1 weeks 0 days ago
    Trigger: Wed 2023-10-25 00:00:00 CEST; 5h 17min left
   Triggers: * logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

dp20eic@iobroker:~$ systemctl status logrotate.service 
* logrotate.service - Rotate log files
     Loaded: loaded (/lib/systemd/system/logrotate.service; static)
     Active: inactive (dead) since Tue 2023-10-24 00:00:43 CEST; 18h ago
TriggeredBy: * logrotate.timer
       Docs: man:logrotate(8)
             man:logrotate.conf(5)
    Process: 89270 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS)
   Main PID: 89270 (code=exited, status=0/SUCCESS)
        CPU: 55ms

Wie rotiert wird, steht in den Files unter /etc/logrotate.d z.b. so sieht das bei meinem Debian - Bookworm aus

dp20eic@iobroker:~$ ls -la /etc/logrotate.d/*
-rw-r--r-- 1 root root 120 Apr 19  2019 /etc/logrotate.d/alternatives
-rw-r--r-- 1 root root 173 May 12  2020 /etc/logrotate.d/apt
-rw-r--r-- 1 root root 130 Aug 29  2018 /etc/logrotate.d/btmp
-rw-r--r-- 1 root root 181 Nov 28  2020 /etc/logrotate.d/cups-daemon
-rw-r--r-- 1 root root 112 Apr 19  2019 /etc/logrotate.d/dpkg
-rw-r--r-- 1 root root 374 Feb 17  2021 /etc/logrotate.d/rsyslog
-rw-r--r-- 1 root root 131 Jul 29  2021 /etc/logrotate.d/telegraf
-rw-r--r-- 1 root root 145 Feb 19  2018 /etc/logrotate.d/wtmp

Wenn da auch wieder nichts kommt, dann setz die Kiste wirklich neu auf, denn dann laborierst du an einem toten Pferd.

VG
Bernd

[erazor86]

@dp20eic

kaum zu glauben, zwischen meinem letzten und diesen Post wurde mein zweiter Sohn geboren. Bin gerade ausm Kreissaal zurück, damit hätte ich heute auch nicht mehr gerechnet

nun aber zurück zum Thema
es sieht so aus, als würde soweit alles laufen...

Last login: Tue Oct 24 17:00:14 2023 from 192.168.178.117
pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        55G  5.1G   48G  10% /
devtmpfs        1.8G     0  1.8G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G   17M  1.9G   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sda1       253M   49M  204M  20% /boot
tmpfs           384M     0  384M   0% /run/user/1000
pi@raspberrypi:~ $ lsof /var/log/kern.log
pi@raspberrypi:~ $ systemctl status logrotate.timer
● logrotate.timer - Daily rotation of log files
   Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled; vendor preset:
   Active: active (waiting) since Tue 2023-10-24 16:41:25 CEST; 7h ago
  Trigger: Thu 2023-10-26 00:00:00 CEST; 23h left
     Docs: man:logrotate(8)
           man:logrotate.conf(5)

Oct 24 16:41:25 raspberrypi systemd[1]: Started Daily rotation of log files.
...skipping...
● logrotate.timer - Daily rotation of log files
   Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled; vendor preset:
   Active: active (waiting) since Tue 2023-10-24 16:41:25 CEST; 7h ago
  Trigger: Thu 2023-10-26 00:00:00 CEST; 23h left
     Docs: man:logrotate(8)
           man:logrotate.conf(5)

Oct 24 16:41:25 raspberrypi systemd[1]: Started Daily rotation of log files.

pi@raspberrypi:~ $ systemctl status logrotate.service
● logrotate.service - Rotate log files
   Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset:
   Active: inactive (dead) since Wed 2023-10-25 00:00:15 CEST; 37min ago
     Docs: man:logrotate(8)
           man:logrotate.conf(5)
  Process: 29578 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited,
 Main PID: 29578 (code=exited, status=0/SUCCESS)

Oct 25 00:00:14 raspberrypi systemd[1]: Starting Rotate log files...
Oct 25 00:00:15 raspberrypi systemd[1]: logrotate.service: Succeeded.
Oct 25 00:00:15 raspberrypi systemd[1]: Started Rotate log files.

pi@raspberrypi:~ $ ls -la /etc/logrotate.d/*
-rw-r--r-- 1 root root 120 Apr 19  2019 /etc/logrotate.d/alternatives
-rw-r--r-- 1 root root 173 Apr 19  2021 /etc/logrotate.d/apt
-rw-r--r-- 1 root root 130 Aug 29  2018 /etc/logrotate.d/btmp
-rw-r--r-- 1 root root 112 Apr 19  2019 /etc/logrotate.d/dpkg
-rw-r--r-- 1 root root 501 Feb 26  2019 /etc/logrotate.d/rsyslog
-rw-r--r-- 1 root root 145 Feb 19  2018 /etc/logrotate.d/wtmp
pi@raspberrypi:~ $

ich bin mir allerdings nicht sicher ob ich den rsyslog wieder starten sollte... er wird ja aktuell unter dem Befehl

pi@raspberrypi:~ $ lsof /var/log/kern.log

nicht als aktiv aufgeführt, aber das wurde er im Laufe des Tages definitiv einmal.. vermutlich habe ich ihn nach dem stoppen nicht wieder gestartet...?

edit: Was mir noch aufgefallen ist, das ganze Theater begann ja heute morgen als ich den mihome-vacuum adapter einrichten wollte. Wenn ich diesen Deinstallieren möchte, tut er das lt.log auch. Die Instanz und auch die Objekte sind alle weg.. Aber er wird immer noch als installiert unter den Adaptern aufgeführt ...?
Ansonsten läuft und verhält sich der Iobroker wieder ganz normal.

[A Former User]

@erazor86 sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:

n und diesen Post wurde mein zweiter Sohn geboren. Bin gerade ausm Kreissaal zurück, damit hätte ich heute auch nicht mehr gerechnet

Moin,

mein Glückwunsch, und alles Gute für Mama und dem neuen Erdenbürger, dem großen Bruder und natürlich dem Papa.

VG
Bernd

[A Former User]

@erazor86 sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:

Ansonsten läuft und verhält sich der Iobroker wieder ganz normal

Moin,

eigentlich meinte ich nicht, dass Du mir hier die Files für Logrotate noch einmal zeigst, sondern, dass Du Dir diese einmal anschauen solltest, was da drin steht um zu verstehen was Logrotate macht

@erazor86 sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:

ich bin mir allerdings nicht sicher ob ich den rsyslog wieder starten sollte

Wenn Du ihn nicht startest, dann werden einige Logfiles nicht mehr geschrieben, dann wachsen die auch nicht mehr an, aber sollte es ein Problem/Fehler geben, dann hat mal halt auch keine System-Logfiles.
Ist also eine Entscheidung, die Du treffen musst.

@erazor86 sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:

Die Instanz und auch die Objekte sind alle weg.. Aber er wird immer noch als installiert unter den Adaptern aufgeführt ...?

Was hast Du genau gemacht?
Wenn Du nur unter dem Reiter Instanz die Instanz gelöscht hast, dann ist auch nur diese und die dazugehörigen Objekte gelöscht, Du musst auch den Adapter löschen.
Du kannst Dir anschauen, welche Adapter Du installiert hast und eine oder mehrere Instanz(en) haben

Du kannst Dir anschauen welche Adapter Du installiert hast, die aber keine Instanz haben

Hier sollte bei Dir noch der mihome-vaccum auftauchen!

Und Du hast eine Gesamtübersicht über alle Adapter

Wenn Du nicht nur die Instanz, sondern auch den Adapter löschen möchtest, dann

Man sieht, der Adapter ist noch installiert, hat aber keine Instanz mehr

Jetzt ist er auch unter den Instanz losen Adaptern zu finden

Um den Adapter zu deinstallieren, auf die drei Punkte klicken

Und dann auf den Mülleimer

Du kannst natürlich auch gleich im Adapter auf den Mülleimer klicken, dann werden meistens, erst die Objekte, dann die Instanz, und dann der Adapter gelöscht.

VG
Bernd

[erazor86]

@dp20eic danke für die Glückwünsche

okay verstanden mit dem logrotate.

Das mit den Instanzen und Adaptern verstehe ich soweit. Ich würde mal behaupten mit iobroker selbst habe ich deutlich mehr Erfahrung als mit Linux.. sobald was mit dem BS ist, werde ich direkt nervös

ich habe zuerst die Instanz gelöscht und danach wollte ich den Adapter löschen, aber beim Adapter löschen verschwindet er nicht aus der Übersicht der installierten Adapter ohne Instanzen.

edit: okay als ich gerade die Situation nachstellen wollte und einen screenshot einfügen wollte, taucht er aufeinmal nicht mehr unter den installierten adaptern auf. dann hat es wohl doch alles geklappt

nun werde ich aber parallel mal den zweiten raspi aufsetzen. sobald das system läuft und iob installiert ist, kann ich dann einfach die Backups von dem aktuellen drüber bügeln?

[A Former User]

@erazor86 sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:

system läuft und iob installiert ist, kann ich dann einfach die Backups von dem aktuellen drüber bügeln?

Moin,

Radio Eriwan sagt, dazu, ja eigentlich schon

Ablauf ist

• Betriebssystem installieren -> Debian light Bookworm
  • mit einem persönlichen User und sudo support
• Updates durchführen -> sudo apt update, sudo apt full-upgrade
• ioBroker mittels Einzeiler installieren
• falls VIS genutzt wird, dann den Adapter installieren
• BackitUp Adapter konfigurieren
• Backup File entweder auf die neue Maschine kopieren oder BackupitUp so einrichten, dass auf den Remote Store zugegriffen werden kann
• Restore des ioBrokers
• warten
• warten
• warten
• warten
• warten
• warten
• warten
• warten
• warten
• warten
• falls Geräte über IP mit dem ioBroker sprechen, diese auf die neue IP umstellen
• fertig

VG
Bernd

[erazor86]

Hallo zusammen,

nachdem ich das System im Oktober auf meinem zweiten Raspi neu aufgespielt habe inkl. Backup einspielen etc, läuft bisher alles einwandfrei.

Da nun zwischenzeitlich wieder einige Adapter etc. Updates anbieten, möchte ich diesmal nicht wieder Jahre warten bis alles komplett veraltet ist, sondern alle paar Monate mal das System mit allen Adaptern etc. auf Stand halten.
Hierzu würde ich jedoch gerne von euch nochmal eine kurze Info haben, in welcher Reihenfolge ich jetzt was am besten mit welchen Befehlen etc. aktualisiere, damit ich mir nicht schon wieder irgendwas zerschieße.

Also zuerst System? NPM? Node JS? Adapter...

Anbei mal ein paar Screenshots auf welchem Stand ich mich gerade befinde:

Adapterupdates:

Iobroker host:

System:

[Thomas Braun]

@erazor86

Immer von 'unten nach oben' vorgehen:

sudo apt update
iob stop
sudo apt upgrade
sudo reboot
iob update
iob upgrade all
iob stop
iob upgrade self
iob restart

Und das ganze so alle zwei Wochen, würde ich empfehlen.

[erazor86]

@thomas-braun okay danke erstmal für die Info.
Damit ist dann alles abgedeckt? Kannst du das kurz erläutern was dahinter steckt? also welche Reihenfolge? Ich vermute zuerst werden die Adapter geupdatet, dann iobroker gestoppt und dann die Systemteile?

Wieso sind die Updates in so kurzen Zeitabständen notwendig wenn alles ordnungsgemäß läuft?

[Thomas Braun]

@erazor86 sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:

Wieso sind die Updates in so kurzen Zeitabständen notwendig wenn alles ordnungsgemäß läuft?

Weil konstant Updates eintrudeln. Je mehr da in der Pipeline steckt desto komplizierter kann das werden. Deswegen schwimmt man da regelmäßig mit.

Dhie Reihenfolge ist genau wie oben aufgeführt. Zuerst das Betriebssystem, dann die ioBroker-Adapter, dann der js-controller.