NEWS
Iobroker nicht mehr erreichbar / Festplatte voll?
-
@dp20eic sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:
/var(log/kern.log
Das sollte eher jeweils
/var/log/kern.log
lauten.
-
@dp20eic said in Iobroker nicht mehr erreichbar / Festplatte voll?:
sudo ls -la /var/log/kern.log*
ich habe die Befehle mal nacheinander gestartet, aber da scheint es noch irgendwo zu hängen
pi@raspberrypi:~ $ sudo lsof /var/log/kern.log pi@raspberrypi:~ $ sudo systemctl status ● raspberrypi State: degraded Jobs: 0 queued Failed: 1 units Since: Thu 1970-01-01 01:00:01 CET; 53 years 9 months ago CGroup: / ├─user.slice │ └─user-1000.slice │ ├─session-3.scope │ │ ├─3038 sshd: pi [priv] │ │ ├─3090 sshd: pi@pts/1 │ │ ├─3091 -bash │ │ ├─4139 sudo systemctl status │ │ ├─4140 systemctl status │ │ └─4141 pager │ ├─user@1000.service │ │ └─init.scope │ │ ├─748 /lib/systemd/systemd --user │ │ └─749 (sd-pam) │ └─session-1.scope │ ├─678 sshd: pi [priv] │ ├─762 sshd: pi@pts/0 │ └─763 -bash lines 1-23...skipping... ● raspberrypi State: degraded Jobs: 0 queued Failed: 1 units Since: Thu 1970-01-01 01:00:01 CET; 53 years 9 months ago CGroup: / ├─user.slice │ └─user-1000.slice │ ├─session-3.scope │ │ ├─3038 sshd: pi [priv] │ │ ├─3090 sshd: pi@pts/1 │ │ ├─3091 -bash │ │ ├─4139 sudo systemctl status │ │ ├─4140 systemctl status │ │ └─4141 pager │ ├─user@1000.service │ │ └─init.scope │ │ ├─748 /lib/systemd/systemd --user │ │ └─749 (sd-pam) │ └─session-1.scope │ ├─678 sshd: pi [priv] │ ├─762 sshd: pi@pts/0 │ └─763 -bash ├─init.scope │ └─1 /sbin/init └─system.slice ├─alsa-state.service │ └─361 /usr/sbin/alsactl -E HOME=/run/alsa -s -n 19 -c rdaemon ├─systemd-timesyncd.service │ └─311 /lib/systemd/systemd-timesyncd ├─dbus.service │ └─349 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only ├─hciuart.service │ └─643 /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow - ├─ssh.service │ └─631 /usr/sbin/sshd -D ├─avahi-daemon.service │ ├─358 avahi-daemon: running [raspberrypi.local] │ └─373 avahi-daemon: chroot helper ├─system-getty.slice │ └─getty@tty1.service │ └─630 /sbin/agetty -o -p -- \u --noclear tty1 linux ├─wpa_supplicant.service │ └─372 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant ├─triggerhappy.service │ └─376 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody --deviceglob /dev/input/event* ├─systemd-logind.service │ └─389 /lib/systemd/systemd-logind ├─cron.service │ └─356 /usr/sbin/cron -f ├─systemd-udevd.service │ └─152 /lib/systemd/systemd-udevd ├─rsyslog.service │ └─4039 /usr/sbin/rsyslogd -n -iNONE ├─bluetooth.service │ └─658 /usr/lib/bluetooth/bluetoothd ├─systemd-journald.service │ └─134 /lib/systemd/systemd-journald ├─rng-tools.service │ └─351 /usr/sbin/rngd -r /dev/hwrng └─dhcpcd.service ├─486 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext lines 1-62 ● raspberrypi State: degraded Jobs: 0 queued Failed: 1 units Since: Thu 1970-01-01 01:00:01 CET; 53 years 9 months ago CGroup: / ├─user.slice │ └─user-1000.slice │ ├─session-3.scope │ │ ├─3038 sshd: pi [priv] │ │ ├─3090 sshd: pi@pts/1 │ │ ├─3091 -bash │ │ ├─4139 sudo systemctl status │ │ ├─4140 systemctl status │ │ └─4141 pager │ ├─user@1000.service │ │ └─init.scope │ │ ├─748 /lib/systemd/systemd --user │ │ └─749 (sd-pam) │ └─session-1.scope │ ├─678 sshd: pi [priv] │ ├─762 sshd: pi@pts/0 │ └─763 -bash ├─init.scope │ └─1 /sbin/init └─system.slice ├─alsa-state.service │ └─361 /usr/sbin/alsactl -E HOME=/run/alsa -s -n 19 -c rdaemon ├─systemd-timesyncd.service │ └─311 /lib/systemd/systemd-timesyncd ├─dbus.service │ └─349 /usr/bin/dbus-daemon --system --address=systemd: --nofork - ├─hciuart.service │ └─643 /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow - ├─ssh.service │ └─631 /usr/sbin/sshd -D ├─avahi-daemon.service │ ├─358 avahi-daemon: running [raspberrypi.local] │ └─373 avahi-daemon: chroot helper ├─system-getty.slice │ └─getty@tty1.service │ └─630 /sbin/agetty -o -p -- \u --noclear tty1 linux ├─wpa_supplicant.service │ └─372 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant ├─triggerhappy.service │ └─376 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --so ├─systemd-logind.service │ └─389 /lib/systemd/systemd-logind ├─cron.service │ └─356 /usr/sbin/cron -f ├─systemd-udevd.service │ └─152 /lib/systemd/systemd-udevd ├─rsyslog.service │ └─4039 /usr/sbin/rsyslogd -n -iNONE ├─bluetooth.service │ └─658 /usr/lib/bluetooth/bluetoothd ├─systemd-journald.service │ └─134 /lib/systemd/systemd-journald ├─rng-tools.service │ └─351 /usr/sbin/rngd -r /dev/hwrng └─dhcpcd.service ├─486 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf └─623 /sbin/dhcpcd -q -w pi@raspberrypi:~ $ sudo systemctl stop Too few arguments. pi@raspberrypi:~ $ sudo lsof /var/log/kern.log pi@raspberrypi:~ $ sudo > /dev/log/kern.log -bash: /dev/log/kern.log: Not a directory pi@raspberrypi:~ $ sudo > /dev/log/kern.log -bash: /dev/log/kern.log: Not a directory pi@raspberrypi:~ $ sudo systemctl start Too few arguments. pi@raspberrypi:~ $ sudo ls -la /var/log/kern.log* -rw-r----- 1 root adm 12281625684 Oct 24 16:41 /var/log/kern.log -rw-r----- 1 root adm 456 Sep 23 20:36 /var/log/kern.log.1 -rw-r----- 1 root adm 298 Sep 18 17:02 /var/log/kern.log.2.gz -rw-r----- 1 root adm 24217 Sep 5 09:56 /var/log/kern.log.3.gz -rw-r----- 1 root adm 189 Aug 27 21:59 /var/log/kern.log.4.gz
-
echo "" | sudo tee /var/log/kern.log
sollte das kern.log löschen. Analog
echo "" | sudo tee /var/log/syslog
-
@thomas-braun said in Iobroker nicht mehr erreichbar / Festplatte voll?:
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
-
@erazor86 sagte in Iobroker nicht mehr erreichbar / Festplatte voll?:
sudo systemctl status
Moin,
nach dem
status
muss natürlich auch das eingetragen werden, was beilsof
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äuftdp20eic@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 meinemDebian - Bookworm
ausdp20eic@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 -
@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. -
@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 -
@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 ReiterInstanz
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 Duinstalliert
hast und eine oder mehrereInstanz(en)
haben
Du kannst Dir anschauen welche Adapter Du
installiert
hast, die aber keineInstanz
haben
Hier sollte bei Dir noch dermihome-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 -
@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?
-
@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
- mit einem persönlichen User und
- 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 - Betriebssystem installieren -> Debian light Bookworm
-
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:
-
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.
-
@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?
-
@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.