Server friert nach Update auf 6.12 willkürlich nachts ein

[alturismo]

37 minutes ago, LyDjane said:

Mit der neuen Version ist der Fehler vermutlich immer noch vorhanden oder?

Nein, mit der 6.12.4 ist es gefixt, Anleitung bitte lesen und umsetzen bzgl. bridge und Docker Netzwerken !!!

[hawihoney]

38 minutes ago, LyDjane said:

Mit der neuen Version ist der Fehler vermutlich immer noch vorhanden oder?

 

Welcher Fehler? Das große Problem der 6.12.x war die MACVLAN Problematik. Das ist mit 6.12.4 behoben. Allerdings sollte man sich, sofern man davon betroffen ist, die Release-Notes zu Herzen nehmen und abarbeiten. In Kürze: Network Bonding=yes, Network Bridging=no, Docker Host access to custom networks=yes.

 

[LyDjane]

Guten Morgen zusammen,

 

Update wurde gefahren.

Einstellungen sind derzeit folgendermaßen:

Settings > Network Settings > eth0 > Enable Bonding = Yes

Settings > Network Settings > eth0 > Enable Bridging = No

Settings > Docker > Host access to custom networks = Enabled

Das sollte dann doch genau so bei mir im Fall funktionieren, oder?

Vielen Dank und euch ein schönes Wochenende!

[LyDjane]

Meine Systemauslastung ist seitdem Update bei 100% dauerhaft

[LyDjane]

Server hat sich beruhigt und wieder normale Auslastung.
Bisher läuft alles tadellos.

[Jochen Kklaus]

On 9/17/2023 at 10:26 AM, LyDjane said:

 

Settings > Docker > Host access to custom networks = Enabled
 

Hallo zusammen,

 

ist dieser Punkt eigentlich Pflicht für einen fehlerfreien Betrieb? Weil eigentlich brauche ich diese Funktion nicht.

 

Gruß

Jochen

[alturismo]

3 hours ago, Jochen Kklaus said:

ist dieser Punkt eigentlich Pflicht für einen fehlerfreien Betrieb? Weil eigentlich brauche ich diese Funktion nicht.

 

dann lass es aus  Nein, ist keine Pflicht.

[Reflexion]

'n Abend zusammen,

ich hänge mich mal hier mal mit dran, sollte ich damit stören, mache ich natürlich ein separaten Topic auf,...

 

Ich habe schon länger Probleme auch nach dem Wechsel von Intel zu AMD mit regelmäßigen einfrieren (hatte ich auch schon hier in der Vergangenheit in anderen Topic's geschildert), nicht mehr erreichen des Servers. Reboot half dann meist für eine kurze Zeitspanne.

 

Hellhörig wurde ich jetzt bei der These, und eben dem, was "LyDjane" beschrieb, denn auch mein Server dreht willkürlich mein Ryzen Server auf, nach einer halben Stunde war das noch immer der Fall. Es geht um folgendes Setup;

 

Unraid Basic 6.12.4
Thermaltake The Tower 100 Mini Tower Schwarz
SAMSUNG 32GB Flash Drive FIT Plus USB-Stick (Boot-Stick)

AMD Ryzen 7 PRO 5750G
Samsung DIMM 32GB, DDR4-3200, CL22, ECC (M391A4G43BB1-CWEQ)
Samsung DIMM 32GB, DDR4-3200, CL22, ECC (M391A4G43BB1-CWEQ)
GIGABYTE B550I AORUS Pro AX rev. 1.1 BIOS; F18b (aktuell)

Pool:
Asus Hyper M.2 X16 Card V2 (es werden leider max: x4x4x8 unterstützt)
Lexar NM620 2TB, M.2 (cache) btrfs
Lexar NM620 2TB, M.2 (cache2) btrfs

Array:
Lexar NM790 4TB, M.2 (parity)
Western Digital WD Blue SN570 NVMe SSD 2TB, M.2 (Disk1) (xfs)
Transcend SSD230S 4TB, SATA (Disk2) (xfs)
Transcend SSD230S 4TB, SATA (Disk3) (xfs)

Netzteil:
Seasonic Focus 450Watt SFX

 

Gemessen mit; denver smart home app;
Idle ~28Watt

 

Fritzbox 6690 cable (Vodafone,  dual Stack, kein CGNAT)

 

Einstellungen wurden wie oben bei "LyDjane" gesetzt;

 

Einstellungen sind derzeit folgendermaßen:

Settings > Network Settings > eth0 > Enable Bonding = Yes

Settings > Network Settings > eth0 > Enable Bridging = No

Settings > Docker > Host access to custom networks = Enabled

 

 

 

 

Auffällig ist, dass vor allem ein Thread fast durchwegs auf 100% taktet.. ich habe dann die Kiste einmal neu gestartet und es war ruhe im Karton. ... ansonsten war erstmal alles wie gewohnt.. 1-2% Auslastung, smb Zugriff funktionierte.. WireGuard VPN ebenfalls, alles fein..

 

Dann am späten  Abend wieder, die Kiste dreht voll auf nur diesmal habe ich mich dann pennen gelegt, auf den NVMe array/pool war auch nicht aktiv, kein R/W Datentransfer, zwei Container liefen (DuckDNS/Zerotier) lediglich und WireGuard eben über das System selbst.

Ich dachte lass den Server mal arbeiten, womit auch immer...

 

Heute Morgen dann direkt geschaut und gestaunt, die LOG Datei war voll, laut dem Webinterface, glücklicherweise kam ich überhaupt noch auf das WebUI und konnte bis auf das Starten des Docker Updaters (endlose Suche...) auch auf die Option ohne Einfrieren zugreifen.. habe schnellstmöglich die Option gesetzt für das LOG Schreiben auf dem Boot-Stick, via smb konnte ich darauf auch zugreifen und retten ... zumindest bis etwa ~35MB geschrieben waren.. danach kam ich dann auch nicht mehr auf der WebUI weiter... 

 

Die „wenigen“ LOG Datei Einträge wiederholen sich stetig, ich poste deshalb lieber nur einen kleinen der "syslog";

 

"....

Sep 20 08:26:44 TowerRyzen5750G rsyslogd: file '/var/log/syslog'[5] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2102.0 try https://www.rsyslog.com/e/2027 ]
Sep 20 08:26:44 TowerRyzen5750G rsyslogd: action 'action-0-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try https://www.rsyslog.com/e/2027 ]
Sep 20 08:26:44 TowerRyzen5750G rsyslogd: file '/var/log/syslog'[5] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2102.0 try https://www.rsyslog.com/e/2027 ]
Sep 20 08:26:44 TowerRyzen5750G rsyslogd: action 'action-0-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try https://www.rsyslog.com/e/2027 ]
Sep 20 08:26:44 TowerRyzen5750G rsyslogd: file '/var/log/syslog'[5] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2102.0 try https://www.rsyslog.com/e/2027 ]
Sep 20 08:26:44 TowerRyzen5750G kernel: BTRFS error (device nvme0n1p1): invalid free space control: bg start=30408704 len=1073741824 total_bitmaps=8394709 unit=4096 max_bitmaps=8 bytes_per_bg=134217728
Sep 20 08:26:44 TowerRyzen5750G kernel: BTRFS error (device nvme0n1p1): invalid free space control: bg start=30408704 len=1073741824 total_bitmaps=8394710 unit=4096 max_bitmaps=8 bytes_per_bg=134217728
Sep 20 08:26:44 TowerRyzen5750G kernel: BTRFS error (device nvme0n1p1): invalid free space control: bg start=30408704 len=1073741824 total_bitmaps=8394711 unit=4096 max_bitmaps=8 bytes_per_bg=134217728
Sep 20 08:26:44 TowerRyzen5750G kernel: BTRFS error (device nvme0n1p1): invalid free space control: bg start=30408704 len=1073741824 total_bitmaps=8394712 unit=4096 max_bitmaps=8 bytes_per_bg=134217728
Sep 20 08:26:44 TowerRyzen5750G kernel: BTRFS error (device nvme0n1p1): invalid free space control: bg start=30408704 len=1073741824 total_bitmaps=8394713 unit=4096 max_bitmaps=8 bytes_per_bg=134217728
Sep 20 08:26:44 TowerRyzen5750G kernel: BTRFS error (device nvme0n1p1): invalid free space control: bg start=30408704 len=1073741824 total_bitmaps=8394714 unit=4096 max_bitmaps=8 bytes_per_bg=134217728
Sep 20 08:26:44 TowerRyzen5750G kernel: BTRFS error (device nvme0n1p1): invalid free space control: bg start=30408704 len=1073741824 total_bitmaps=8394715 unit=4096 max_bitmaps=8 bytes_per_bg=134217728

Sep 20 08:26:48 TowerRyzen5750G kernel: _btrfs_printk: 846 callbacks suppressed
...."

 

Ich habe mehrfach Parity checks, und unter Docker

"Correct file system errors" mit Korrektur durchlaufen lassen. Auch den fix "Common Problems Befehl"  und die beiden Tests unter;

"Update Assistant Disk Utilities" .

 Auch habe ich versucht, mit dem Befehl: 

"append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 pcie_aspm=off"

in den Loader des USB-Sticks einzutragen. 

 , ein Unterschied machte das nicht bezüglich der Stabilität, auf das array konte ich eh immer zugreifen, auch auf das pool selbst.. 

Aufgrund dessen strich ich denn ASPM Killer dann mal wieder.

Im BIOS habe ich "C-States" deaktiviert, auch wenn das Problem mit Abstürzen/Einfrieren gefixt worden sein soll/te.

Ach und den  ECC uREG RAM habe ich auch ausgetauscht und betreibe ihn auf dem Default Status.

 

..habt Ihr noch eine Idee? Danke für evtl. Anregungen..

 

 

 

 

Edited September 20, 2023 by Reflexion

[mgutt]

On 9/20/2023 at 11:44 PM, Reflexion said:

file '/var/log/syslog'[5] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device

unRAID läuft im RAM, wie auch diese Datei. Dein RAM läuft also warum auch immer voll. Das ist natürlich nicht normal.

 

Meist liegt es an Dateien, die in Verzeichnissen gespeichert werden, wo sie nicht sein sollten. 

 

Mit dem Kommando kannst du die jeweilige Belegung prüfen:

 

du -hsx /* 2> /dev/null

 

So sieht es bei mir aus:

12M     /bin
715M    /boot
0       /dev
15M     /etc
0       /home
0       /hugetlbfs
0       /init
8.2M    /lib
30M     /lib64
0       /mnt
0       /opt
0       /proc
20K     /root
1.1M    /run
23M     /sbin
0       /sys
76M     /tmp
776M    /usr
13M     /var

 

Weicht bei dir etwas auffällig ab?

[LyDjane]

1 hour ago, mgutt said:

 

Mit dem Kommando kannst du die jeweilige Belegung prüfen:

 

du -hsx /* 2> /dev/null

 

So sieht es bei mir aus:

12M     /bin
715M    /boot
0       /dev
15M     /etc
0       /home
0       /hugetlbfs
0       /init
8.2M    /lib
30M     /lib64
0       /mnt
0       /opt
0       /proc
20K     /root
1.1M    /run
23M     /sbin
0       /sys
76M     /tmp
776M    /usr
13M     /var

 

Weicht bei dir etwas auffällig ab?

 

Bei mir schaut es tatsächlich so aus:

12M     /bin
921M    /boot
0       /dev
15M     /etc
0       /home
0       /hugetlbfs
0       /init
0       /lib
36M     /lib64
0       /mnt
184M    /opt
532K    /portainer
0       /proc
24K     /root
2.8M    /run
23M     /sbin
0       /sys
35M     /tmp
0       /usr
474M    /var

[mgutt]

2 hours ago, LyDjane said:

184M    /opt

Was ist in diesem Ordner?

 

Und wie sieht aktuell deine RAM Auslastung aus? Eventuell wiederholst du das Kommando einfach alle paar Stunden / Tage, um eine Tendenz auszumachen.

 

2 hours ago, LyDjane said:

474M    /var

Das wirkt auch als sei es zu viel. Mich wundert auch, dass /usr bei dir nichts zählt. Hat unRAID dafür neuerdings eine separate Partition? Führe bitte mal df -h aus.

[Reflexion]

@mgutt Danke Dir erstmal für die Mühe, ich selbst hatte schon auf Verdacht, dass der RAM kaputt sei, diesen getauscht aber eben keine Besserung.. daher auch noch die Vermutung, dass seitens des uEFI's noch im Bereich ECC Anpassungen getätigt wären müssen.

 

Seit zwei Tagen sieht es nun recht ruhig aus, lediglich das „log“ file hat sich um 1% erhöht.:

 

„du -hsx /* 2> /dev/null“, Ergebnis, rechts @mgutt und links dann meine Ergebnisse, „/lib“, „/Usr“, „/var“,  ist hier recht auffällig.

 

Ich habe hier nochmal meine Docker Einstellungen, leider bekomme ich nicht mehr eingeblendet (MacVLAN vs IPvlan Thematik);                                                                                                                               

 

 

 Ansonsten laufen nur die beiden Container:

 

Zu den ECC Einstellungen im uEFI;

 

Edited September 24, 2023 by Reflexion

[LyDjane]

1 hour ago, mgutt said:

Was ist in diesem Ordner?

Zwei weitere Ordner mit "containerd" und "microsoft"

 

1 hour ago, mgutt said:

Und wie sieht aktuell deine RAM Auslastung aus? Eventuell wiederholst du das Kommando einfach alle paar Stunden / Tage, um eine Tendenz auszumachen.

 

schwankt immer zwischen 35% und 61%.
 

 

1 hour ago, mgutt said:

Führe bitte mal df -h aus.

Filesystem      Size  Used Avail Use% Mounted on
rootfs           20G  777M   19G   4% /
tmpfs            32M  2.8M   30M   9% /run
/dev/sda1        30G  922M   29G   4% /boot
overlay          20G  777M   19G   4% /lib
overlay          20G  777M   19G   4% /usr
devtmpfs        8.0M     0  8.0M   0% /dev
tmpfs            20G     0   20G   0% /dev/shm
tmpfs           384M   15M  370M   4% /var/log
/dev/md1p1      7.3T  3.4T  4.0T  47% /mnt/disk1
/dev/nvme0n1p1  932G   93G  838G  10% /mnt/cache
shfs            7.3T  3.4T  4.0T  47% /mnt/user0
shfs            7.3T  3.4T  4.0T  47% /mnt/user
/dev/loop2      100G   19G   78G  19% /var/lib/docker

 

[mgutt]

Mit RAM Defekt hat das nichts zu tun. Da gäbe es andere Fehler. Jetzt musst du einfach warten bis der Fehler erneut nachvollziehbar ist. Wie gesagt schreibt irgendwas in den RAM oder überlastet im Allgemeinen den RAM.