Cupra-Bo Posted November 8, 2021 Share Posted November 8, 2021 Nabend .. bin gerade nach Hause gekommen.. Server Läuft aber alles nicht erreichbar Docker VM und Gui TOT Bildschirm angemacht auch tot also er hatte Signal aber alles Schwarz ... Neustart alles wieder da ... gibts hier nen Log wo ich evtl nen Fehler sehen kann was da war ? Gruß Quote Link to comment
Ford Prefect Posted November 8, 2021 Share Posted November 8, 2021 6 minutes ago, Cupra-Bo said: Bildschirm angemacht auch tot also er hatte Signal aber alles Schwarz ...normal...hast Du ein keyboard dran? ... Taste drücken...SPACE ist ungefährlich 6 minutes ago, Cupra-Bo said: gibts hier nen Log wo ich evtl nen Fehler sehen kann was da war ? ...jetzt nicht mehr. Du kannst in den Einstellungen festlegen, dass das syslog auf den Stick mitgeschrieben wird....falls es dann nochmal auftritt Quote Link to comment
Cupra-Bo Posted November 8, 2021 Author Share Posted November 8, 2021 (edited) Hab dann nen Keyboard angesteckt und wie du Sagst leertaste keine Raktion ... Kann du mir kurz sagen wo ich das einstellen kann ? würde auch auf den Cache gehn der ist eh immer an Edit: Glaub habs gefunden Syslog da kann ich ja in Appdata schreiben Edited November 8, 2021 by Cupra-Bo Quote Link to comment
Cupra-Bo Posted November 27, 2021 Author Share Posted November 27, 2021 (edited) so ich noch mal heute wieder das Problem hier mal der Syslog Warum er da so Faxen macht das mein Receiver sich verbindet weiß ich nicht aber das ist Täglich drin.. davon sollte der Crash nicht kommen 11:45 uhr hab ich dann hart Reset gemacht Nov 27 03:40:01 Tower root: mover: started Nov 27 03:40:01 Tower root: mover: finished Nov 27 07:00:03 Tower root: /var/lib/docker: 2.5 GiB (2699571200 bytes) trimmed on /dev/loop2 Nov 27 07:00:03 Tower root: /etc/libvirt: 25.2 MiB (26472448 bytes) trimmed on /dev/loop3 Nov 27 07:00:03 Tower root: /mnt/cache: 82.9 GiB (88973389824 bytes) trimmed on /dev/sdi1 Nov 27 07:30:35 Tower rpcbind[8632]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:30:35 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:1016 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:30:35 Tower rpcbind[8633]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:30:46 Tower rpcbind[8874]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:30:46 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:818 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:30:46 Tower rpcbind[8875]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:30:57 Tower rpcbind[9170]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:30:57 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:772 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:30:57 Tower rpcbind[9171]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:31:08 Tower rpcbind[9452]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:31:08 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:789 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:31:08 Tower rpcbind[9453]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:31:19 Tower rpcbind[9752]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:31:19 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:846 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:31:19 Tower rpcbind[9753]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:31:30 Tower rpcbind[10012]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:31:30 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:942 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:31:30 Tower rpcbind[10013]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:31:41 Tower rpcbind[10292]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:31:41 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:712 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:31:41 Tower rpcbind[10293]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:31:52 Tower rpcbind[10551]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:31:52 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:968 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:31:52 Tower rpcbind[10552]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:32:03 Tower rpcbind[10891]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:32:03 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:950 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:32:03 Tower rpcbind[10892]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:32:14 Tower rpcbind[11130]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:32:14 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:925 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:32:14 Tower rpcbind[11131]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:32:25 Tower rpcbind[11429]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:32:25 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:721 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:32:25 Tower rpcbind[11430]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:32:36 Tower rpcbind[11717]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:32:36 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:878 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:32:36 Tower rpcbind[11718]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:32:47 Tower rpcbind[12006]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:32:47 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:796 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:32:47 Tower rpcbind[12007]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:32:58 Tower rpcbind[12275]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:32:58 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:747 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:32:58 Tower rpcbind[12276]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:33:09 Tower rpcbind[12614]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:33:09 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:794 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:33:09 Tower rpcbind[12615]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:33:20 Tower rpcbind[12879]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:33:20 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:957 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:33:20 Tower rpcbind[12880]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:33:42 Tower rpcbind[13461]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:33:42 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:988 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:33:42 Tower rpcbind[13462]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:33:53 Tower rpcbind[13703]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:33:53 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:929 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:33:53 Tower rpcbind[13704]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:34:04 Tower rpcbind[14042]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:34:04 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:811 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:34:04 Tower rpcbind[14043]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:34:15 Tower rpcbind[14298]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:34:15 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:735 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:34:15 Tower rpcbind[14300]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:34:26 Tower rpcbind[14599]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:34:26 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:766 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:34:26 Tower rpcbind[14600]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:34:37 Tower rpcbind[14865]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:34:37 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:737 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:34:37 Tower rpcbind[14866]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:34:48 Tower rpcbind[15154]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:34:48 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:787 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:34:48 Tower rpcbind[15155]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:34:59 Tower rpcbind[15421]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:34:59 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:824 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:34:59 Tower rpcbind[15422]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:35:10 Tower rpcbind[15775]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:35:10 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:799 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:35:10 Tower rpcbind[15776]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 07:35:21 Tower rpcbind[16042]: connect from 192.168.177.4 to getport/addr(mountd) Nov 27 07:35:21 Tower rpc.mountd[5488]: authenticated mount request from 192.168.177.4:846 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen) Nov 27 07:35:21 Tower rpcbind[16043]: connect from 192.168.177.4 to getport/addr(nfs) Nov 27 11:46:11 Tower kernel: microcode: microcode updated early to revision 0x28, date = 2019-11-12 Nov 27 11:46:11 Tower kernel: Linux version 5.10.28-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Wed Apr 7 08:23:18 PDT 2021 Nov 27 11:46:11 Tower kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Nov 27 11:46:11 Tower kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Nov 27 11:46:11 Tower kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Nov 27 11:46:11 Tower kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Nov 27 11:46:11 Tower kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Nov 27 11:46:11 Tower kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Nov 27 11:46:11 Tower kernel: BIOS-provided physical RAM map: Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000c9b57fff] usable Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000c9b58000-0x00000000c9b5efff] ACPI NVS Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000c9b5f000-0x00000000c9cb7fff] usable Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000c9cb8000-0x00000000ca426fff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000ca427000-0x00000000ca468fff] usable Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000ca469000-0x00000000ca749fff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000ca74a000-0x00000000dadd0fff] usable Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000dadd1000-0x00000000dae67fff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000dae68000-0x00000000dae8cfff] ACPI data Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000dae8d000-0x00000000db005fff] ACPI NVS Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000db006000-0x00000000dbffefff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000dbfff000-0x00000000dbffffff] usable Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved Nov 27 11:46:11 Tower kernel: BIOS-e820: [mem 0x0000000100000000-0x000000041fdfffff] usable Nov 27 11:46:11 Tower kernel: NX (Execute Disable) protection: active Nov 27 11:46:11 Tower kernel: SMBIOS 2.7 present. Nov 27 11:46:11 Tower kernel: DMI: Hewlett-Packard 500-308ng/2AF7, BIOS 80.15 04/15/2014 Nov 27 11:46:11 Tower kernel: tsc: Fast TSC calibration using PIT Nov 27 11:46:11 Tower kernel: tsc: Detected 2893.350 MHz processor Edited November 27, 2021 by Cupra-Bo Quote Link to comment
mgutt Posted November 27, 2021 Share Posted November 27, 2021 Ich sehe keine Fehler. Hast du Container im br0 Netzwerk? Auch VMs? Bei br0 kann es zu Konflikten kommen, die zu einem Absturz führen können. Oder nutzt du ein AMD Board, das unter dem USB Bug leidet? Da was mit tsc in den Logs auftaucht wäre auch die Frage ob du eine Intel CPU verwendest, die unter dem hpet Bug leidet. Noch ein Grund können ASPM Fehler bezogen auf NVMes sein. Ansonsten Klassiker wie defekter RAM, etc. Letzteres würde ich zuerst mal prüfen. Also nur mit einem RAM Modul Booten und den Memory Test machen. Dann beim nächsten usw. Quote Link to comment
Cupra-Bo Posted November 27, 2021 Author Share Posted November 27, 2021 Zur ersten Frage 2 mal ja nutze intel CPU und eine M2 ist auch verbaut .. was verstehst du unter Memory machen ? gibts da was in unraid zum Check ? Gruß Quote Link to comment
mgutt Posted November 27, 2021 Share Posted November 27, 2021 3 hours ago, Cupra-Bo said: was verstehst du unter Memory machen ? gibts da was in unraid zum Check ? Ja beim Booten kannst du den Memorytest auswählen. Welche Intel CPU und welche NVMe sind verbaut? Lass dir doch nicht alles aus der Nase ziehen. 🧐 Quote Link to comment
Cupra-Bo Posted November 27, 2021 Author Share Posted November 27, 2021 (edited) oki Memtest lass ich die Tage mal laufen .. Kingston KC600 512GB SSD SATA3 mSATA - SKC600MS/512GB ------ Sprich eine msata und keine m2 .. Intel® Core™ i5-4460S CPU Board ist ein HP ipmb7-mp Edited November 27, 2021 by Cupra-Bo Quote Link to comment
Cupra-Bo Posted December 2, 2021 Author Share Posted December 2, 2021 so hatte die tage mal memtest laufen vollbestückt also meine 2 Riegel .. 4 stunden ohne Fehler ... Heute das gleiche spiel wieder komm heim Server Hängt Werde jetzt mal memtest Starten und morgen Früh schauen wie es ausschaut . Bin für jeden weiteren Tipp Dankbar Quote Link to comment
alturismo Posted December 2, 2021 Share Posted December 2, 2021 zum einen im bios die energie spar einstellungen retour setzen falls da was gemacht wurde. was noch (leider) einige betrifft, docker, custom:br0 in benutzung ? wenn ja mit docker host access ? das führt bei manchen system anscheinend zum "stillstand", falls das aktiviert ist mal ohne testen was passiert. Quote Link to comment
Cupra-Bo Posted December 3, 2021 Author Share Posted December 3, 2021 Also memtest heute Früh nach 10 Stunden keinen Fehler ... Wegen netzwerk br0 hab ich immer bei Dockern die ne Extra IP haben oder VM´s wie kann ich das ändern das ich Trotzdem ne andere IP vergeben kann ? Bios Settings muss ich mal bei Gelegenheit Checken .. bei dem Bios ist das aber eh eher so ne MAU auswahl Quote Link to comment
mgutt Posted December 3, 2021 Share Posted December 3, 2021 17 minutes ago, Cupra-Bo said: Wegen netzwerk br0 hab ich immer bei Dockern die ne Extra IP haben oder VM´s wie kann ich das ändern das ich Trotzdem ne andere IP vergeben kann ? Update auf unRAID 6.10 und dort bei den Docker Einstellungen auf IPVLAN ändern. Das soll es wohl beheben. 1 Quote Link to comment
Cupra-Bo Posted December 3, 2021 Author Share Posted December 3, 2021 (edited) ist das nen Bug ? Stell bei Update auf Next um und dann oben auf Aktualiesieren ... er findet die 6.10 aber sobald ich auf Fertig klicke springt er wieder auf die Stable Edit: ok habs hinbekommen lag am Browser -.- Edited December 3, 2021 by Cupra-Bo Quote Link to comment
alturismo Posted December 3, 2021 Share Posted December 3, 2021 2 hours ago, Cupra-Bo said: ist das nen Bug ? nicht wirklich, hier läuft es schon immer stabil mit macvlan, in 6.10 xx hast du die Wahl, macvlan oder ipvlan, aber Achtung, Fritzboxen kriegen da Ihre Probleme mit ipvlan ... da dann zwar auch jeder Docker per custom:br0 seine eigene ip hat aber alle die gleiche mac haben, sprich, nameserver in der Fritz springt hin und her da hier anscheinend mit an der mac gebunden ... und nochmals zur Frage, es gibt einige wo mit macvlan das Problem haben mit "unraid nicht mehr erreichbar, usw usw ...", da stellen die meisten dann doch komplett auf ein bridge only setup um mit port mappings usw usw .... gilt es einfach zu testen. und, ich bevorzuge auch nur macvlan mit custom:br0, aber wie erwähnt, bei manchen will es einfach nicht stabil laufen ... Quote Link to comment
Cupra-Bo Posted December 4, 2021 Author Share Posted December 4, 2021 hatte bei meinem HP Microserver Gen8 auch nie probleme ... Aber am neues Server scheint es hier bissi zu zwicken. Hab jetzt mal auf IPVlan geändert und sonst gar nix gemacht mal sehen was die nächsten Tage sprechen, Fritzbox scheint bisher keine Probleme zu haben Quote Link to comment
Cupra-Bo Posted December 10, 2021 Author Share Posted December 10, 2021 (edited) Also Fazit "KACKE" tage sind wieder rum und die Kiste hängt wieder also an IPvlan hat es nicht gelegen keinen plan wie es bei den anderen Crashes war, Aber jetzt ist das letzte im LOG vor dem Crash trimmed.. Stromspar Optionen im Bios gibts weiter keine eine mit Sata war noch aktiv die hab ich jetzt mal Deaktiviert .. Glaub aber nicht dran das es daran Liegt Dec 10 03:40:17 Tower emhttpd: read SMART /dev/sdf Dec 10 04:41:48 Tower emhttpd: spinning down /dev/sdf Dec 10 04:41:58 Tower emhttpd: spinning down /dev/sdh Dec 10 04:41:58 Tower emhttpd: spinning down /dev/sde Dec 10 07:00:02 Tower root: /var/lib/docker: 2.5 GiB (2699091968 bytes) trimmed on /dev/loop2 Dec 10 07:00:02 Tower root: /etc/libvirt: 24.5 MiB (25669632 bytes) trimmed on /dev/loop3 Dec 10 07:00:02 Tower root: /mnt/cache: 53.4 GiB (57307086848 bytes) trimmed on /dev/sdi1 Dec 10 15:17:58 Tower kernel: microcode: microcode updated early to revision 0x28, date = 2019-11-12 Dec 10 15:17:58 Tower kernel: Linux version 5.14.15-Unraid (root@Develop) (gcc (GCC) 11.2.0, GNU ld version 2.37-slack15) #1 SMP Thu Oct 28 09:56:33 PDT 2021 Dec 10 15:17:58 Tower kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Dec 10 15:17:58 Tower kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Dec 10 15:17:58 Tower kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Dec 10 15:17:58 Tower kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Dec 10 15:17:58 Tower kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Dec 10 15:17:58 Tower kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Dec 10 15:17:58 Tower kernel: signal: max sigframe size: 1776 Dec 10 15:17:58 Tower kernel: BIOS-provided physical RAM map: Kann es am Trimmed liegen ? EDIT; Das hat er aber jeden Tag früh somit denk ich eher weniger Edited December 10, 2021 by Cupra-Bo Quote Link to comment
mgutt Posted December 10, 2021 Share Posted December 10, 2021 Wäre die Frage in wie weit es die Hardware sein könnte. zB ein sterbendes Netzteil. Macht doch mal einen Stresstest. Installiere dir das stress Paket: wget https://packages.slackonly.com/pub/packages/14.2-x86_64/system/stress/stress-1.0.4-x86_64-1_slonly.txz -P /tmp upgradepkg --install-new /tmp/stress-1.0.4-x86_64-1_slonly.txz Und dann entsprechend der Anzahl deiner CPU Kerne das ausführen: stress --cpu 4 Parallel dazu schickst du deine Platten in den Spindown und fährst sie wieder hoch. Also maximale Last auf dem Netzteil simulieren. Quote Link to comment
Cupra-Bo Posted December 10, 2021 Author Share Posted December 10, 2021 hab ich gerade mal gemacht ... läuft cool weiter die kiste .. kumpel von mir hat noch ein NT von mir evtl das mal zum test einbauen ... weil früh um 7 macht der Server eigentlich gar nix -.- Quote Link to comment
mgutt Posted December 10, 2021 Share Posted December 10, 2021 Der sinkt aber vom Verbrauch nicht so tief, dasa das Netzteil abschaltet? Wobei aus ist er ja nicht, sondern gefreezt, richtig? Ansonsten hol dir doch was anderes. Bei dem Alter bekommt man das doch für wenig Geld. Vielleicht hat auch der RAM eine Macke?! Quote Link to comment
Cupra-Bo Posted December 11, 2021 Author Share Posted December 11, 2021 Richtig er ist noch an.. Bin ja erst vom HP Gen8 Microserver auf den gewechselt (den neue hab ich geschenkt bekommen kumpel sein alter PC) grund für den wechsel war der Stromverbrauch und dabei mehr Leistung. Kann man mit Unraid Neustart Aufgabenplanung machen ? Hab zudem jetzt mal die Trimm Funktion ausgemacht .. die ich Täglich früh um 7 uhr Laufen hatte Quote Link to comment
mgutt Posted December 11, 2021 Share Posted December 11, 2021 8 hours ago, Cupra-Bo said: Kann man mit Unraid Neustart Aufgabenplanung machen ? Das User Scripts Plugin installieren und ein Skript dafür erstellen. Der Befehl "reboot" in eine Zeile packen und dann die Zeit festlegen. Wäre jetzt allerdings nur ein Dirty Hack für dein Problem. Was ist denn mit einem RAM Test? Quote Link to comment
Cupra-Bo Posted December 11, 2021 Author Share Posted December 11, 2021 2 hours ago, mgutt said: Das User Scripts Plugin installieren und ein Skript dafür erstellen. Der Befehl "reboot" in eine Zeile packen und dann die Zeit festlegen. Wäre jetzt allerdings nur ein Dirty Hack für dein Problem. Was ist denn mit einem RAM Test? Ja klar wäre das nur ein nicht so guter Trick und ob er Hilft steht in den Sternen Memtest hatte ich mal laufen übernacht siehe Bild ohne Errors Quote Link to comment
greenflash24 Posted December 12, 2021 Share Posted December 12, 2021 On 12/3/2021 at 11:08 PM, alturismo said: nicht wirklich, hier läuft es schon immer stabil mit macvlan, in 6.10 xx hast du die Wahl, macvlan oder ipvlan, aber Achtung, Fritzboxen kriegen da Ihre Probleme mit ipvlan ... da dann zwar auch jeder Docker per custom:br0 seine eigene ip hat aber alle die gleiche mac haben, sprich, nameserver in der Fritz springt hin und her da hier anscheinend mit an der mac gebunden ... Ich hatte bei meinem Server auch wöchentlich lockups aufgrund Docker container die per custom:br0 mittels macvlan angebunden waren. Seitdem ich auf ipvlan umgestellt habe, läuft mein System stabil mit einer Uptime von über 50 Tagen. Leider habe ich auch eine FritzBox im Einsatz, die mit dem ipvlan wohl nicht ganz klar kommt. Im Heimnetz sind alle IPs problemlos erreichbar, jedoch funktionieren nun einige Portfreigaben in der FritzBox nicht mehr und ich kann auch keine neuen mehr anlegen. Hat von euch zufällig jemand eine Idee, wie man container mit einer eigenen IP über custom:br0 mittels ipvlan sinnvoll an einer FritzBox nutzen kann, oder muss zwingend ein "vernünftiger" Router her? Quote Link to comment
mgutt Posted December 12, 2021 Share Posted December 12, 2021 46 minutes ago, greenflash24 said: Hat von euch zufällig jemand eine Idee, wie man container mit einer eigenen IP über custom:br0 mittels ipvlan sinnvoll an einer FritzBox nutzen kann, oder muss zwingend ein "vernünftiger" Router her? Das Problem ist meine ich, dass ipvlan keine MAC-Adressen vergibt. @Ford Prefect haben andere Switche damit keine Probleme? Quote Link to comment
Ford Prefect Posted December 12, 2021 Share Posted December 12, 2021 21 minutes ago, mgutt said: Das Problem ist meine ich, dass ipvlan keine MAC-Adressen vergibt. @Ford Prefect haben andere Switche damit keine Probleme? Ich denke nicht, dass es ein L2 Problem bei der Fritz gibt. Die und auch andere Switche werden damit kein Problem haben. Meine Mikrotik Switches haben das auf jeden Fall nicht Es ist ja auch nicht so, das bei ipvlans keine MAC vergeben wird, die IPs haben - von Aussen betrachtet - nur alle dieselbe MAC. Das Problem der Fritz ist, dass L2 und L3 zwingend 1:1 sein muss...die ist vom User-Konzept halt nicht dafür ausgelegt, dass eine MAC mehr als eine IP tragen kann. Problematisch bei der Fritz wird es erst recht, wenn mehr als ein IP-Netz am Start ist und VLANs kann sie garnicht. ...die Hardware könnte das wahrscheinlich sogar alles (eine ge-freezte Fritz kann VLANs). Deswegen kein Switch Problem, sondern eher L3 und DNS....muss man halt einen anderen, lokalen DNS nutzen. Aber ich nutze eben die Fritten garnicht mehr (doch eine 7272, als SIP/Telefonie Client und DECT Basis - im IP client mode, nicht als Router). Ich nutze seither ausschliesslich macvlan (in Verbindung mit VLANs) und habe damit noch nie Problem gehabt. Lockups schon garnicht. Wenn ein Docker das nicht kann, fliegt er raus oder muss umgebaut werden. Allein Portainer bildet eine Ausnahme, da der auf der unraid IP lauschen muss um den Docker-Daemon zu sehen, läuft der auf der platten "bridge". 2 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.