Bebbo

As the bug appears to originate within huge_memory.c, would it be worth turning off transparent huge pages and seeing if that cures the issue? There seems to be a lot of issues with hugepages at the moment and looking at the kernel forums there seem to be unresolved issues with splitting pages, particularly with Docker as it also uses hugepages if they are enabled. See this post for details on turning off THP - https://forums.unraid.net/bug-reports/stable-releases/crashes-since-updating-to-v611x-for-qbittorrent-and-deluge-users-r2153/?do=findComment&comment=21761 Alternatively you could add transparent_hugepage=never to the end of your flash drive syslinux config (Main -> Flash -> syslinux configuration -> Unraid OS -> add to end of append statement 'append initrd=/bzroot transparent_hugepage=never')

That's odd, the qbittorrent build config appears to require the addition of a flag to include libtorrent 2.x otherwise it will default to building with 1.2.18?

I had some odd issues when I reverted and found some data corruption in my docker images (possibly from crashes in 6.11.1). I removed everything and re-installed all dockers and plugins and it has been running perfectly since. Might be worth a shot?

Not sure if it is related to the problems you are having but some part of the mover appears to have hard-coded paths and names for cache pools (probably been there since Unraid only allowed a single cache pool). I noted that you are getting errors in your log the same as I do and it is probably owing to us not naming our cache pool 'cache'. Oct 27 02:30:19 Zen root: mvlogger: Share Name Only: mydata Oct 27 02:30:19 Zen root: mvlogger: Cache Pool Name: cache Oct 27 02:30:19 Zen root: mvlogger: cache Threshold Pct: Oct 27 02:30:19 Zen root: mvlogger: OVERALL Threshold: 0 Oct 27 02:30:19 Zen root: mvlogger: Share Path: /mnt/cache/mydata Oct 27 02:30:19 Zen root: df: /mnt/cache: No such file or directory Oct 27 02:30:19 Zen root: mvlogger: Pool Pct Used: % Oct 27 02:30:19 Zen root: mvlogger: DFTPCT LIMIT USED FOR SETTING: 0 Oct 27 02:30:19 Zen root: /usr/local/emhttp/plugins/ca.mover.tuning/age_mover: line 305: [: -gt: unary operator expected Oct 27 02:30:19 Zen root: mvlogger: Threshold Used: 0

Hi. Sorry, I don't have the answer for you regarding WG on Unraid but I thought I would mention that if you are using a Fritz!Box device (which it looks like from the screen shots), they have a Fritz Labs version available for most routers that now has Wireguard functionality. This quickly solved similar issues I was having with lack of handshake (and lack of any meaningful feedback in wireguard on my client devices).

And as above, I have the same error message displayed. API Report: <-----UNRAID-API-REPORT-----> SERVER_NAME: Zen ENVIRONMENT: production UNRAID_VERSION: 6.10.3 UNRAID_API_VERSION: 2.52.1 (running) NODE_VERSION: v18.5.0 API_KEY: valid MY_SERVERS: authenticated MY_SERVERS_USERNAME: Bebbo CLOUD: ok [IP=52.40.54.163] RELAY: connected MINI-GRAPH: connected ONLINE_SERVERS: Zen[owner="Bebbo"] OFFLINE_SERVERS: ALLOWED_ORIGINS: http://localhost, http://IPV4ADDRESS, https://IPV4ADDRESS, http://zen, https://zen, http://zen.local, https://zen.local, https://HASH.unraid.net HAS_CRASH_LOGS: yes </----UNRAID-API-REPORT-----> <-----UNRAID-API-CRASH-LOGS-----> PID 13291 received SIGSEGV for address: 0x0 /tmp/pkg/85fc9a0e8a73534c4faeec0ec66b716757255ef4d0559b9473aed94f84658b19/segfault-handler/build/Release/segfault-handler.node(+0x37a5)[0x145f065a67a5] /lib64/libpthread.so.0(+0x123a0)[0x145f062143a0] /usr/local/sbin/unraid-api(_ZN2v88internal18MarkingVisitorBaseINS0_24ConcurrentMarkingVisitorENS0_22ConcurrentMarkingStateEE23ProcessStrongHeapObjectINS0_18FullHeapObjectSlotEEEvNS0_10HeapObjectET_S7_+0x27)[0x13675c7] /usr/local/sbin/unraid-api(_ZN2v88internal17ConcurrentMarking3RunEPNS_11JobDelegateENS_4base7EnumSetINS0_13CodeFlushModeEiEEjb+0x4598)[0x136d9f8] /usr/local/sbin/unraid-api(_ZN2v88internal17ConcurrentMarking7JobTask3RunEPNS_11JobDelegateE+0xa0)[0x136fee0] /usr/local/sbin/unraid-api[0xe57b3c] /usr/local/sbin/unraid-api[0xa7191c] /lib64/libpthread.so.0(+0x7e45)[0x145f06209e45] /lib64/libc.so.6(clone+0x3f)[0x145f0612e4af] PID 3112 received SIGSEGV for address: 0x0 /tmp/pkg/85fc9a0e8a73534c4faeec0ec66b716757255ef4d0559b9473aed94f84658b19/segfault-handler/build/Release/segfault-handler.node(+0x37a5)[0x14564043b7a5] /lib64/libpthread.so.0(+0x123a0)[0x1456400a93a0] /usr/local/bin/unraid-api/unraid-api(_ZN2v88internal6String11WriteToFlatIhEEvS1_PT_iiNS0_16PtrComprCageBaseERKNS0_31SharedStringAccessGuardIfNeededE+0x58)[0x1671f38] /usr/local/bin/unraid-api/unraid-api(_ZN2v88internal6String11WriteToFlatIhEEvS1_PT_ii+0x19)[0x16721a9] /usr/local/bin/unraid-api/unraid-api(_ZN2v88internal6String11SlowFlattenEPNS0_7IsolateENS0_6HandleINS0_10ConsStringEEENS0_14AllocationTypeE+0x240)[0x1672410] /usr/local/bin/unraid-api/unraid-api(_ZN2v88internal7Factory18NewProperSubStringENS0_6HandleINS0_6StringEEEii+0x564)[0x1388db4] /usr/local/bin/unraid-api/unraid-api(_ZN2v88internal23Runtime_StringSubstringEiPmPNS0_7IsolateE+0x5a)[0x1792aaa] /usr/local/bin/unraid-api/unraid-api[0x1bb6239] <-----UNRAID-API-CRASH-LOGS-----> System diagnostic attached. zen-diagnostics-20221004-1308.zip

There are a couple of different ways of setting this up on your router but probably the easiest to understand is creating two entries as follows: 1. Custom Config Service Name: HTTP (Swag) Protocol: TCP External Port: 80 Internal Port: 8001 Internal IP Address: <Your Swag Machine IP> 2. Custom Config Service Name: HTTPS (Swag) Protocol: TCP External Port: 443 Internal Port: 44301 Internal IP Address: <Your Swag Machine IP>