Server stürzt regelmäßig ab / Ist nicht mehr erreichbar

JannikGHG · April 8

Guten Tag,

seit Wechsel auf neues Unraid Build (nur gebrauchte Hardware) habe ich regelmäßig Abstürze und es lässt sich nicht mehr auf den Server / die Applikationen zugreifen. Ich habe aber die Vermutung, dass es an einem Docker Container oder so liegt, weil der Server lief mit Plugins und gestartem Array und Docker Service und VM Manager länger durch. Bis ich angefangen habe die Docker Container zu starten bei einem Test.

Stress Test der CPU und Memtest lief ohne Probleme

Diagnostics habe ich mal hochgeladen. Heute der letzte Crash war um spätestens Apr 8 04:38:45 da sind davor auch einige merkwürdige Fehler in dem Syslog sichtbar.

Vielen Dank für die Hilfe

JannikGHG · April 8

unraid-diagnostics-20240408-1131.zip

alturismo · April 8

14 minutes ago, JannikGHG said:

Heute der letzte Crash war um spätestens Apr 8 04:38:45 da sind davor auch einige merkwürdige Fehler in dem Syslog sichtbar.

dein log fängt erst um Apr 8 08:29:19 an ...

da du anscheinend Fritz User bist, prüf mal ob alles eingestellt ist wie unter Anleitungen, macvlan issues (angepinnter Thread)

brudge scheint aus zu sein, macvlan aktiv ? host access (scheint an zu sein)

JannikGHG · April 8

22 minutes ago, alturismo said:

dein log fängt erst um Apr 8 08:29:19 an ...

da du anscheinend Fritz User bist, prüf mal ob alles eingestellt ist wie unter Anleitungen, macvlan issues (angepinnter Thread)

brudge scheint aus zu sein, macvlan aktiv ? host access (scheint an zu sein)

Habe ich gestern Abend alles tatsächlich noch vor dem letzten Crash auf MACVLAN gestellt. Muss ich die Docker Container die auf bridge stehen alle noch auf eth0 mit eigener IP Adresse umstellen?

Anbei noch der Log vor dem Crash und Screenshots bzgl. MACVLAN

syslog before crash.txt

Edited April 8 by JannikGHG

alturismo · April 8

24 minutes ago, JannikGHG said:

und Screenshots bzgl. MACVLAN

so passt das alles, bis 01.04. hattest du noch call traces

aktuell liegt es wohl eher daran ... die Meldungen wiederholen sich ca. 1000x

Apr  8 04:38:02 UNRAID winbindd[32597]:   dumping core in /var/log/samba/cores/winbindd
Apr  8 04:38:02 UNRAID winbindd[32597]: 
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011314,  0] ../../lib/util/fault.c:173(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   ===============================================================
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011334,  0] ../../lib/util/fault.c:174(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   INTERNAL ERROR: Signal 11: Segmentation fault in pid 32609 (4.17.12)
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011338,  0] ../../lib/util/fault.c:178(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011343,  0] ../../lib/util/fault.c:183(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   ===============================================================
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011345,  0] ../../lib/util/fault.c:184(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   PANIC (pid 32609): Signal 11: Segmentation fault in 4.17.12
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011517,  0] ../../lib/util/fault.c:292(log_stack_trace)
Apr  8 04:38:02 UNRAID winbindd[32609]:   BACKTRACE: 42 stack frames:
Apr  8 04:38:02 UNRAID winbindd[32609]:    #0 /usr/lib64/libgenrand-samba4.so(log_stack_trace+0x2e) [0x14e9409e964e]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #1 /usr/lib64/libgenrand-samba4.so(smb_panic+0x9) [0x14e9409e98a9]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #2 /usr/lib64/libgenrand-samba4.so(+0x2937) [0x14e9409e9937]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #3 /lib64/libc.so.6(+0x3ae20) [0x14e94048ae20]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #4 /usr/lib64/libsamba-sockets-samba4.so(+0x6270) [0x14e941042270]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #5 /usr/lib64/libsamba-sockets-samba4.so(+0xaee0) [0x14e941046ee0]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #6 /usr/lib64/libsamba-sockets-samba4.so(tstream_writev_send+0x166) [0x14e941043c36]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #7 /usr/lib64/libmsrpc3-samba4.so(+0x1282a) [0x14e94150d82a]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #8 /usr/lib64/libtevent.so.0(tevent_common_invoke_immediate_handler+0x17a) [0x14e940879e2a]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #9 /usr/lib64/libtevent.so.0(tevent_common_loop_immediate+0x16) [0x14e940879e46]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #10 /usr/lib64/libtevent.so.0(+0xebfb) [0x14e94087fbfb]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #11 /usr/lib64/libtevent.so.0(+0xcef7) [0x14e94087def7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #12 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14e940878ba1]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #13 /usr/lib64/libtevent.so.0(tevent_req_poll+0x23) [0x14e94087a993]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #14 /usr/lib64/libtevent-util.so.0(tevent_req_poll_unix+0xe) [0x14e9414c145e]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #15 /usr/lib64/libmsrpc3-samba4.so(local_np_connect+0xb8) [0x14e94150e7d8]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #16 /usr/lib64/libmsrpc3-samba4.so(rpc_pipe_open_local_np+0x13e) [0x14e94150a07e]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #17 /usr/sbin/winbindd(wb_open_internal_pipe+0x4d) [0x55761894e56d]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #18 /usr/sbin/winbindd(open_internal_samr_conn+0x36) [0x55761895cba6]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #19 /usr/sbin/winbindd(+0x4ce68) [0x55761895ce68]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #20 /usr/sbin/winbindd(+0x4e8c7) [0x55761895e8c7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #21 /usr/sbin/winbindd(wb_cache_name_to_sid+0xaa) [0x55761893e7da]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #22 /usr/sbin/winbindd(_wbint_LookupName+0x3a) [0x55761896779a]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #23 /usr/sbin/winbindd(+0x5c1cc) [0x55761896c1cc]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #24 /usr/lib64/libdcerpc-server-core.so.0(dcesrv_call_dispatch_local+0x64) [0x14e9414d0954]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #25 /usr/sbin/winbindd(winbindd_dual_ndrcmd+0x3bb) [0x5576189647bb]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #26 /usr/sbin/winbindd(+0x508f4) [0x5576189608f4]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #27 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x14e9408798c1]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #28 /usr/lib64/libtevent.so.0(+0xee07) [0x14e94087fe07]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #29 /usr/lib64/libtevent.so.0(+0xcef7) [0x14e94087def7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #30 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14e940878ba1]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #31 /usr/sbin/winbindd(+0x531d8) [0x5576189631d8]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #32 /usr/sbin/winbindd(+0x53a65) [0x557618963a65]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #33 /usr/lib64/libtevent.so.0(tevent_common_invoke_immediate_handler+0x17a) [0x14e940879e2a]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #34 /usr/lib64/libtevent.so.0(tevent_common_loop_immediate+0x16) [0x14e940879e46]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #35 /usr/lib64/libtevent.so.0(+0xebfb) [0x14e94087fbfb]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #36 /usr/lib64/libtevent.so.0(+0xcef7) [0x14e94087def7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #37 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14e940878ba1]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #38 /usr/sbin/winbindd(main+0xb04) [0x55761892dc14]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #39 /lib64/libc.so.6(+0x236b7) [0x14e9404736b7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #40 /lib64/libc.so.6(__libc_start_main+0x85) [0x14e940473775]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #41 /usr/sbin/winbindd(_start+0x21) [0x55761892e9f1]
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011598,  0] ../../source3/lib/dumpcore.c:315(dump_core)
Apr  8 04:38:02 UNRAID winbindd[32609]:   dumping core in /var/log/samba/cores/winbindd
Apr  8 04:38:02 UNRAID winbindd[32609]: 
Apr  8 04:38:02 UNRAID crond[1418]: exit status 126 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null
Apr  8 04:38:08 UNRAID kernel: __vm_enough_memory: pid: 32673, comm: Plex Media Scan, no enough memory for the allocation
Apr  8 04:38:08 UNRAID kernel: __vm_enough_memory: pid: 32673, comm: Plex Media Scan, no enough memory for the allocation
Apr  8 04:38:08 UNRAID kernel: Plex Media Scan[32673]: segfault at 1523b39a00c0 ip 00001523a86aff98 sp 00007ffecb0f3bf0 error 4 in libpython27.so[1523a8599000+179000] likely on CPU 10 (core 20, socket 0)
Apr  8 04:38:08 UNRAID kernel: Code: 5b 41 5c 41 5e 41 5f 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 81 ec b8 00 00 00 49 89 fc 48 8d 05 cf f3 e9 ff 49 89 f6 <0f> bf 16 8d 8a d2 fe ff ff 83 f9 0f 0f 87 7c 01 00 00 48 63 0c 88
Apr  8 04:38:10 UNRAID kernel: traps: Plex Media Scan[32682] general protection fault ip:14b9c9f8e8d8 sp:7ffc69fab440 error:0 in libpython27.so[14b9c9ea6000+179000]
Apr  8 04:38:44 UNRAID kernel: traps: Plex Media Scan[364] general protection fault ip:153d38b03c39 sp:7ffc892317b0 error:0 in libpython27.so[153d38a28000+179000]
Apr  8 04:38:45 UNRAID kernel: traps: Plex Media Scan[369] general protection fault ip:145ecb8cd793 sp:7ffd43ddf498 error:0 in ld-musl-x86_64.so.1[145ecb8bd000+53000]
Apr  8 11:05:46 UNRAID root: Delaying execution of fix common problems scan for 10 minutes

mach hierzu bitte einen report auf, irgendwas Richtung samba haut da böse daneben (geraten) ... inkl. dem log und den diags wie hier.

oder der RAM läuft über wegen falscher Config, beispielsweise eines Dockers ...

Alternativ, alle plugins und Dockers ex bzw. stoppen, nach und nach wieder rein ...

hawihoney · April 8

Schmeiß mal spaßeshalber das System Stats Plugin runter bzw. starte mal im Maintenance Mode.

Edited April 8 by hawihoney

JannikGHG · April 9

On 4/8/2024 at 1:01 PM, alturismo said:

so passt das alles, bis 01.04. hattest du noch call traces

aktuell liegt es wohl eher daran ... die Meldungen wiederholen sich ca. 1000x

Apr  8 04:38:02 UNRAID winbindd[32597]:   dumping core in /var/log/samba/cores/winbindd
Apr  8 04:38:02 UNRAID winbindd[32597]: 
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011314,  0] ../../lib/util/fault.c:173(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   ===============================================================
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011334,  0] ../../lib/util/fault.c:174(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   INTERNAL ERROR: Signal 11: Segmentation fault in pid 32609 (4.17.12)
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011338,  0] ../../lib/util/fault.c:178(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011343,  0] ../../lib/util/fault.c:183(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   ===============================================================
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011345,  0] ../../lib/util/fault.c:184(smb_panic_log)
Apr  8 04:38:02 UNRAID winbindd[32609]:   PANIC (pid 32609): Signal 11: Segmentation fault in 4.17.12
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011517,  0] ../../lib/util/fault.c:292(log_stack_trace)
Apr  8 04:38:02 UNRAID winbindd[32609]:   BACKTRACE: 42 stack frames:
Apr  8 04:38:02 UNRAID winbindd[32609]:    #0 /usr/lib64/libgenrand-samba4.so(log_stack_trace+0x2e) [0x14e9409e964e]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #1 /usr/lib64/libgenrand-samba4.so(smb_panic+0x9) [0x14e9409e98a9]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #2 /usr/lib64/libgenrand-samba4.so(+0x2937) [0x14e9409e9937]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #3 /lib64/libc.so.6(+0x3ae20) [0x14e94048ae20]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #4 /usr/lib64/libsamba-sockets-samba4.so(+0x6270) [0x14e941042270]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #5 /usr/lib64/libsamba-sockets-samba4.so(+0xaee0) [0x14e941046ee0]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #6 /usr/lib64/libsamba-sockets-samba4.so(tstream_writev_send+0x166) [0x14e941043c36]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #7 /usr/lib64/libmsrpc3-samba4.so(+0x1282a) [0x14e94150d82a]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #8 /usr/lib64/libtevent.so.0(tevent_common_invoke_immediate_handler+0x17a) [0x14e940879e2a]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #9 /usr/lib64/libtevent.so.0(tevent_common_loop_immediate+0x16) [0x14e940879e46]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #10 /usr/lib64/libtevent.so.0(+0xebfb) [0x14e94087fbfb]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #11 /usr/lib64/libtevent.so.0(+0xcef7) [0x14e94087def7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #12 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14e940878ba1]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #13 /usr/lib64/libtevent.so.0(tevent_req_poll+0x23) [0x14e94087a993]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #14 /usr/lib64/libtevent-util.so.0(tevent_req_poll_unix+0xe) [0x14e9414c145e]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #15 /usr/lib64/libmsrpc3-samba4.so(local_np_connect+0xb8) [0x14e94150e7d8]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #16 /usr/lib64/libmsrpc3-samba4.so(rpc_pipe_open_local_np+0x13e) [0x14e94150a07e]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #17 /usr/sbin/winbindd(wb_open_internal_pipe+0x4d) [0x55761894e56d]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #18 /usr/sbin/winbindd(open_internal_samr_conn+0x36) [0x55761895cba6]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #19 /usr/sbin/winbindd(+0x4ce68) [0x55761895ce68]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #20 /usr/sbin/winbindd(+0x4e8c7) [0x55761895e8c7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #21 /usr/sbin/winbindd(wb_cache_name_to_sid+0xaa) [0x55761893e7da]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #22 /usr/sbin/winbindd(_wbint_LookupName+0x3a) [0x55761896779a]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #23 /usr/sbin/winbindd(+0x5c1cc) [0x55761896c1cc]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #24 /usr/lib64/libdcerpc-server-core.so.0(dcesrv_call_dispatch_local+0x64) [0x14e9414d0954]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #25 /usr/sbin/winbindd(winbindd_dual_ndrcmd+0x3bb) [0x5576189647bb]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #26 /usr/sbin/winbindd(+0x508f4) [0x5576189608f4]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #27 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x14e9408798c1]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #28 /usr/lib64/libtevent.so.0(+0xee07) [0x14e94087fe07]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #29 /usr/lib64/libtevent.so.0(+0xcef7) [0x14e94087def7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #30 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14e940878ba1]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #31 /usr/sbin/winbindd(+0x531d8) [0x5576189631d8]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #32 /usr/sbin/winbindd(+0x53a65) [0x557618963a65]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #33 /usr/lib64/libtevent.so.0(tevent_common_invoke_immediate_handler+0x17a) [0x14e940879e2a]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #34 /usr/lib64/libtevent.so.0(tevent_common_loop_immediate+0x16) [0x14e940879e46]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #35 /usr/lib64/libtevent.so.0(+0xebfb) [0x14e94087fbfb]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #36 /usr/lib64/libtevent.so.0(+0xcef7) [0x14e94087def7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #37 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14e940878ba1]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #38 /usr/sbin/winbindd(main+0xb04) [0x55761892dc14]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #39 /lib64/libc.so.6(+0x236b7) [0x14e9404736b7]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #40 /lib64/libc.so.6(__libc_start_main+0x85) [0x14e940473775]
Apr  8 04:38:02 UNRAID winbindd[32609]:    #41 /usr/sbin/winbindd(_start+0x21) [0x55761892e9f1]
Apr  8 04:38:02 UNRAID winbindd[32609]: [2024/04/08 04:38:02.011598,  0] ../../source3/lib/dumpcore.c:315(dump_core)
Apr  8 04:38:02 UNRAID winbindd[32609]:   dumping core in /var/log/samba/cores/winbindd
Apr  8 04:38:02 UNRAID winbindd[32609]: 
Apr  8 04:38:02 UNRAID crond[1418]: exit status 126 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null
Apr  8 04:38:08 UNRAID kernel: __vm_enough_memory: pid: 32673, comm: Plex Media Scan, no enough memory for the allocation
Apr  8 04:38:08 UNRAID kernel: __vm_enough_memory: pid: 32673, comm: Plex Media Scan, no enough memory for the allocation
Apr  8 04:38:08 UNRAID kernel: Plex Media Scan[32673]: segfault at 1523b39a00c0 ip 00001523a86aff98 sp 00007ffecb0f3bf0 error 4 in libpython27.so[1523a8599000+179000] likely on CPU 10 (core 20, socket 0)
Apr  8 04:38:08 UNRAID kernel: Code: 5b 41 5c 41 5e 41 5f 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 81 ec b8 00 00 00 49 89 fc 48 8d 05 cf f3 e9 ff 49 89 f6 <0f> bf 16 8d 8a d2 fe ff ff 83 f9 0f 0f 87 7c 01 00 00 48 63 0c 88
Apr  8 04:38:10 UNRAID kernel: traps: Plex Media Scan[32682] general protection fault ip:14b9c9f8e8d8 sp:7ffc69fab440 error:0 in libpython27.so[14b9c9ea6000+179000]
Apr  8 04:38:44 UNRAID kernel: traps: Plex Media Scan[364] general protection fault ip:153d38b03c39 sp:7ffc892317b0 error:0 in libpython27.so[153d38a28000+179000]
Apr  8 04:38:45 UNRAID kernel: traps: Plex Media Scan[369] general protection fault ip:145ecb8cd793 sp:7ffd43ddf498 error:0 in ld-musl-x86_64.so.1[145ecb8bd000+53000]
Apr  8 11:05:46 UNRAID root: Delaying execution of fix common problems scan for 10 minutes

mach hierzu bitte einen report auf, irgendwas Richtung samba haut da böse daneben (geraten) ... inkl. dem log und den diags wie hier.

oder der RAM läuft über wegen falscher Config, beispielsweise eines Dockers ...

Alternativ, alle plugins und Dockers ex bzw. stoppen, nach und nach wieder rein ...

Ich habe versucht, das Problem zu reproduzieren, indem ich die Docker Container einzeln gestartet habe und einige Zeit gewartet habe, aber es sieht so aus, als ob dies mit verschiedenen Docker-Apps verbunden ist, aber nicht mit allen. Zum Beispiel, Jellyfin läuft gut für ein paar Stunden, dann habe ich Krusader verwendet und die Fehler traten wieder im syslog auf. Außerdem hatte ich heute früh Krusader nicht laufen, aber andere Container und der gleiche Fehler trat auf. Ich habe keine Anhaltspunkte, wonach ich noch suchen soll …

Letztes Syslog nach dem Start vom Absturz habe ich mit angehängt

syslog-192.168.178.2.log

JannikGHG · April 9

On 4/8/2024 at 4:12 PM, hawihoney said:

Schmeiß mal spaßeshalber das System Stats Plugin runter bzw. starte mal im Maintenance Mode.

Ich weiß auf jeden Fall, dass der Server ca. einen Tag ohne gestartete Docker Container, mit gestartetem Array und logischerweise auch Plugins fehlerfrei online bleibt, vermutlich auch länger. Also ist Maintanence Mode schon mal unnötig zum Testen und an den Plugins kann es auch nicht liegen, oder?

hawihoney · April 9

24 minutes ago, JannikGHG said:

Plugins

Versuch es trotzdem mal mit dem Deaktivieren des System Stats Plugins. Das crasht dauernd lt. log. Vielleicht ist es die Kombination aus diesem Plugin mit einem bestimmten Docker Container. Kostet Dich nix wenn Du ohnehin noch auf der Suche bist.

JannikGHG · April 9

54 minutes ago, hawihoney said:

Versuch es trotzdem mal mit dem Deaktivieren des System Stats Plugins. Das crasht dauernd lt. log. Vielleicht ist es die Kombination aus diesem Plugin mit einem bestimmten Docker Container. Kostet Dich nix wenn Du ohnehin noch auf der Suche bist.

Hat leider nicht funktioniert, ich teste jetzt weiter mit jeweils einen der beiden RAM Sticks, dann der andere.

syslog-192.168.178.2 (14).log

JannikGHG · April 11

On 4/9/2024 at 8:54 PM, JannikGHG said:

Hat leider nicht funktioniert, ich teste jetzt weiter mit jeweils einen der beiden RAM Sticks, dann der andere.

syslog-192.168.178.2 (14).log 644.89 kB · 0 downloads

Das hat leider auch nicht geklappt

syslog-192.168.178.2 (15).log

zero_neverload · April 13

Hast du nach der Umstellung der Netzwerkeinstellungen auch die Docker geprüft ob die nun eth0 anstatt br0 übernommen haben?

Manchmal übernimmt das System das nicht.

Kann es sein das dein System in einem Active Directory-Domänenverbund mitglied ist?

Wie sehen denn deine SMB Einstellungen aus? Hast du noch etwas manuel konfiguriert? (SMB Extras?)

Edited April 13 by zero_neverload

zero_neverload · April 13

On 4/11/2024 at 12:19 PM, JannikGHG said:

Hat leider nicht funktioniert, ich teste jetzt weiter mit jeweils einen der beiden RAM Sticks, dann der andere.

Auf dem Bootstick ist auch ein MEM-Test Onboard. Denn könnte man ja auch nochmal laufen lassen um sicher zu gehen, das es nicht doch ein Hardwaredefekt ist.

JannikGHG · April 13

10 hours ago, zero_neverload said:

Hast du nach der Umstellung der Netzwerkeinstellungen auch die Docker geprüft ob die nun eth0 anstatt br0 übernommen haben?

Manchmal übernimmt das System das nicht.

Kann es sein das dein System in einem Active Directory-Domänenverbund mitglied ist?

Wie sehen denn deine SMB Einstellungen aus? Hast du noch etwas manuel konfiguriert? (SMB Extras?)

Die Docker Container stehen bei mir schon immer, und immer noch auf bridge, einige auf host. Muss ich das auf eth0 ändern mit eigener IP-Adresse bei MACVLAN?

Ich habe keine Domäne und auch keine SMB Einstellungen angepasst, memtest habe ich schon laufen lassen da wurden keine Fehler gezeigt.

Habe mir Ersatz Prozessor, Mainboard und RAM bestellt. Bin gerade am Testen, aber es scheint tatsächlich der RAM zu sein, obwohl dieser ja keine Fehler angezeigt hatte und ich hatte jeweils immer nur mit einem getestet sogar also müssten beide defekt sein oder beide Inkompatibel. Aber eigentlich müsste der kompatibel sein.

ASUS ROG STRIX B760-I GAMING WIFI

Corsair Vengeance, DDR5-4800, CL40 - 32 GB Dual-Kit, schwarz

Jetzt habe ich den

Kingston FURY Beast Schwarz DDR5 16GB (2x8GB) 5600MT/s DDR5 CL40 DIMM Desktop Gaming Speicher Kit mit 2 - KF556C40BBK2-16

und damit läuft Unraid bisher ohne Fehlermeldungen, mache nachher noch einen Gegentest mit dem alten RAM, jeweils nur ein Riegel.

zero_neverload · April 13

1 hour ago, JannikGHG said:

Die Docker Container stehen bei mir schon immer, und immer noch auf bridge, einige auf host. Muss ich das auf eth0 ändern mit eigener IP-Adresse bei MACVLAN?

Nur wenn die Docker eine eigene IP haben sollen, muss dort eth0 stehen

image.png.21890e6e92a4537b1336b1f19c78ad42.png

ansonsten steht da glaube ich Custom: br01

Server stürzt regelmäßig ab / Ist nicht mehr erreichbar

Recommended Posts

JannikGHG

Link to comment

JannikGHG

Link to comment

alturismo

Link to comment

JannikGHG

Link to comment

alturismo

Link to comment

hawihoney

Link to comment

JannikGHG

Link to comment

JannikGHG

Link to comment

hawihoney

Link to comment

JannikGHG

Link to comment

JannikGHG

Link to comment

zero_neverload

Link to comment

zero_neverload

Link to comment

JannikGHG

Link to comment

zero_neverload

Link to comment

Join the conversation