UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Marcus007]

Hallo Zusammen,
mein Raspi4 mit M2-USB-SSD bleibt alle 2 Tage hängen.
Nachdem ich nach fast 2 Jahren Dauerbetrieb eine neue SSD und ein aktuelles Betriebssystem installiert habe, hängt sich der Raspi4-4 ca. jeden 2 Tag auf. IObroker hab ich über ein Backup rekonstruiert.
Nach Absturz ist der Raspi auch via ssh nicht mehr erreichbar.
Auf dem Gerät ist IOBroker, InfluxDB und Grafana installiert. Was letztendlich den Absturz verursacht weiß ich nicht.
Somit habe ich bei jedem Absturz die Log Dateien gesammelt. (Iobroker.log; daemon.log; syslog; auth.log; kern.log; debug; user.log)
Auch nach langem Studium, kann ich vor dem Absturzzeitpunkten keine verdächtigen Hinweise finden.
Komisch finde ich, dass zum Absturztermin jeweils ein Bootvorgang in die kern.log geschrieben wird.
Jetzt machte es wahrscheinlich wenig Sinn hier die Logs zu Posten.
Vielleicht kann mir jemand Tips zu potenziellen Hinweisen geben, oder ich hole ein Posting nach.
Für ein paar Tips von Raspi/Unix Fachleuten wäre ich dankbar.

Speicherverlauf zwischen den Abstürzen (senkrechte Spitzen)
nach 6 Monatigem Betrieb lief er bei ca. 1MB vorher noch stabil

BTW: der Telegram Adapter meldet sich immer noch beim Absturz ab.

Gruß
Marcus

[wendy2702]

@marcus007 Zeige das Syslog, iobroker log ca.2 Minuten vor dem „Absturz“ und danach vollständig und sage möglichst genau wann der Absturz war.

Und den output von

dmesg

Sonst suche nach z.B. power, voltage, memory, crash

[Marcus007]

@wendy2702

Hallo wendy2702,
um 20:08h hat sich der Telegram-Adapter abgemeldet.
Um ca 20:35 hab ich wieder eingeschaltet.

dmesg.txt

iobroker_log.txt

syslog.txt

Danke

P.S. Ich hoffe ich habe die Listings richtig eingebunden.

[Thomas Braun]

@marcus007

Feb  3 20:07:14 raspberrypi systemd-fsck[297]: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Feb  3 20:07:14 raspberrypi systemd-fsck[297]:  Automatically removing dirty bit.

Feb  3 20:07:14 raspberrypi kernel: [    1.730568] EXT4-fs (sda2): INFO: recovery required on readonly filesystem
Feb  3 20:07:14 raspberrypi kernel: [    1.730609] EXT4-fs (sda2): write access will be enabled during recovery

Feb  3 20:07:14 raspberrypi kernel: [    1.936870] EXT4-fs (sda2): orphan cleanup on readonly fs
Feb  3 20:07:14 raspberrypi kernel: [    1.944786] EXT4-fs (sda2): 3 orphan inodes deleted

[    1.977973] EXT4-fs (sda2): 2 orphan inodes deleted

Schaut nicht so ganz prima aus.

[Marcus007]

@thomas-braun sagte in Suche Hilfe bei der Log-File Interpretation bei Abstürzen.:

[ 1.977973] EXT4-fs (sda2): 2 orphan inodes deleted

verstehe ich nicht:

/opt/iobroker$ df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       235G  5.6G  220G   3% /
devtmpfs        1.8G     0  1.8G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           768M  808K  767M   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
/dev/sda1       253M   49M  204M  20% /boot
/opt/iobroker$  

wo ist sda2?

[Thomas Braun]

@marcus007 sagte in Suche Hilfe bei der Log-File Interpretation bei Abstürzen.:

'Versteckt' sich hier:

/dev/root       235G  5.6G  220G   3% /

Schau mit

mount | sort

danach.

[Marcus007]

@thomas-braun

Aha:

/opt/iobroker$ mount | sort

cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/dev/sda2 on / type ext4 (rw,noatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1800052k,nr_inodes=84155,mode=755)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
proc on /proc type proc (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=785968k,nr_inodes=819200,mode=755)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
/opt/iobroker$  

Wie kann man so ein Problem beheben? (woraus resultiert es überhaupt?)

[Thomas Braun]

@marcus007

Welches Problem? Das mit deinem Dateisystem und den gelöschten inodes?
System IMMER sauber herunterfahren, NIE den Strom abrupt wegnehmen.

[Marcus007]

@thomas-braun

Wie komm ich zu einem stabil laufenden System?

[wendy2702]

@marcus007 was hat sich denn alles zur vorherigen 2 Jahre laufenden Installation geändert?

[Marcus007]

@wendy2702

Es hat sich eniges geändert:
-neuer offizieller bootloader (hatte die erste inoffizielle USB-Boot Version laufen)
-neue SSD
-Debian 11
-neue IObroker Installion
-node js 14
-Backup vom alten System(Backitup)

wollte eigentlich ein "stabileres" System erreichen.