SinoBreizh

Hello everyone! I want to torrent onto an NVMe SSD share, to take full advantage of its write capabilities. However, I'd like to seed long term from a HDD, where capacity is the priority. What I can think of is to have two shares: one SSD share for incomplete (leeching) downloads, and one HDD share for completed (seeding) downloads. But since you can only map one share in the container /data path, how would I go about doing that? In qBittorrent settings, Downloads -> Saving Management -> Default/Incomplete save path, qBittorrent will only ever see the one share I can map to it, not the second one that's outside the container unless mapped. I don't know how to map that second share to qBittorrent. I've read Trash Guides about downloading to an SSD then having the mover move completed/seeding torrents. It is an alternative, that I'd like to avoid if possible: I'd like to keep my seeding pool and array separate, so my array doesn't get spun up. It's spun down about 90% of the time otherwise. I'm very new to docker containers, and I assume there's a way to do what I describe; but I haven't found one myself, or I lack the knowledge to know what to look for. Thanks in advance!

I don't have pterodactyl set up, so I'd be very interested to hear your results if you do test it! It could help narrow down the performance issue to the server itself (if it's as much of a resource hog with Proton) or the Wine overhead (if it runs better with Proton).

I'm going on a tangent here, but has anyone else noticed extremely high CPU usage when running this server? I have an i3 10100, nothing else is using significant amounts of power (plex, jellyfin, IRC client, qbitorrent, etc all barely use any CPU), and I'm reaching 10% CPU usage at idle, and 55-60% with just 3 players on the server. top/htop seems to confirm this isn't some IOwait "fake" CPU usage. Can anyone else confirm this high CPU usage behaviour? That way I'll know if it's just me or a global issue. Is it the server app itself causing the CPU usage, or the Wine overhead? I have a dozen game servers running, many through Wine, and none go this high with so few players. Depending on the cause of the issue, any idea if this can be fixed? It pretty much doubles my power consumption (45W -> 85W). Seescreenshots for info.

No need to be sorry, don't be so harsh on yourself for the unpaid work you're putting in. I for one really appreciate what you're doing, making life easier for docker newbies like me, on a game that launched less than 48 hours ago of all things. Saves me from spinning up a VM to host servers "the old way" because I don't understand docker well enough to do things myself. Thanks to your docker and everyone's input in this thread, my server's up and friends are playing together - that's what matters! Cheers

I'm updating this thread just because it can prove useful to someone, even though it has spiralled out of control into troubleshooting hell. I've narrowed the issue down to my RAM. I have two kits of identical RAM, bought at separate times. Both kits have the same model numbers, specs, and timings. Both pass MemTest without issue on their own. Put them together however, and they fail MemTest. After further investigation, I have noticed that, while they have the same model numbers, frequencies, and timings, the older kit of RAM is actually single rank, while the newer kit is dual rank. I never knew the kits were different in this manner (as it is not advertised anywhere on the online shop or the manufacturer's website) and never expected this to be an issue - I had always read that the memory controller would "pick the slower of the two" kits and work from there. I also expected memory incompatibilities to be clear and evident, where the PC wouldn't boot at all; not this unexplainable crash situation. This is the only explanation I can find for otherwise identical kits of RAM passing MemTest individually, but failing when put together, no matter what slots are used. I am currently using only the dual rank dual channel kit of RAM, and I've had consistent uptime with no crashes for around a day now. I have also failed to cause crashes as I did before, by sending a huge 125GB file over SMB. I have even reverted qbitorrent back to LibtorrentV2, with no issues so far. I'll update the post if I spoke too soon, but this seems to be it. For now I'm flairing this as the solution, in case it can help someone. TL;DR: when encountering seemingly unexplainable crashes, running MemTest can be a good first step to narrow the issue down.

Never mind, it now crashes even with Docker disabled when sending the test file. I guess it has to be a different issue then. Gives the same error though: general protection fault, probably for non-canonical address I give up for tonight. I'm going to bed and letting Memtest run overnight, just in case. ------------------------- Edit: Welp, Memtest immediately failed with thousands of errors. That also explains why Unraid would crash when ingesting a big file. These sticks were working fine before and are months old. I guess my "new year power brownout" theory is gaining traction. I'll individually test the modules tomorrow. But for fuck's sake; I was thinking of buying a UPS too since I'm starting to use Unraid more. I'm not closing this thread as solved until I can confirm everything works with good RAM, hope you don't mind.

I was about to say things were looking good since I switched qbitorrent to use libtorrentv1 instead of libtorrentv2, but I encountered a crash while doing something else. The problem is reproducible 100% of the time. I had attempted to copy over SMB a large (125GB) file from my NVMe-equipped desktop to my NVMe Unraid cache pool; so as to test the SSD's SLC cache limit. However, at some point during the copy process, throughput falls to zero and Unraid crashes in the following seconds. I haven't included the syslog or diagnostics, because there's no errors. Nothing. Only the console hooked up to the server has info: Crash 1 starts with: BUG: Bad page state in process shfs pfn:952a66 Crash 2 starts with: BUG: Bad page state in process smbd pfn: 2a090b Crash 3 starts with: general protection fault, probably for non-canonical address Most crashes end with a kernel panic. Others are an endless loop of trace calls. What makes me think it is related to the issue I posted here for, is the fact that disabling docker seems solves the issue entirely. I have not been able to reproduce the crash with docker disabled. I can copy the 125GB file over SMB back and forth with no issue, and it fully saturates my 10G network (1,2GB/s). Yet unlike in my previous comments, the syslog is completely clean. So it can't be the same issue? And what makes the issue reproducible every single time; why is a large file over SMB what triggers the qbitorrent kernel panic? SMART data shows the SSD is only at 20TB written out of a marketed life of 200TB. The few attributes I get seem to indicate all is normal. The Crucial P1 is known as a hot running drive, but unreliable it is not. I will be purchasing another NVMe drive to rule out the hardware side - needed a second drive for parity on the cache pool anyways. For now I'm just confused. I thought I had narrowed down the issue, but a whole other can of worms is now open. Any help is appreciated.

I've read your thread @JorgeB, and I've decided to try another option proposed there, before I commit to disabling plugins I rely on. I've edited my binhex/qbitorrent-vpn container to pull from @binhex's libtorrentv1 library, and will run it as a daily driver to see if things improve. If no crashes/similar errors occur, then we can confirm your thread was the issue, without having to resort to wiping my plugins. If it still crashes, then I'll wipe the plugins as you asked. From my understanding of the thread you linked, this issue (if it is indeed what you suspect) should be solved with the release of 6.13 since it will run on the 6.5+ kernel. Correct? Anyways, thanks as usual for your time and help.

First of all, happy new year! Didn't expect anyone to be online so soon in 2024. Got it, I'll dig in and report back as soon as my parity drive finishes rebuilding. I think it's completely unrelated, but I woke up this morning to a disabled parity drive and a bunch of errors in syslog. I wasn't too fresh this morning and forgot to download the syslog and the diagnostics, but the drive does pass the SMART test with no issues, and I checked all cable connections to make sure there were no loose fittings. So I don't think the problem is from the drive's health or my SATA cables. All I can think of is a brownout/very short power cut over the new year. And I don't think it's related to the main problem I posted here for.

I've checked your post, and while some things are similar ("Call Trace"; <TASK>; the general syntax of the errors), it's not exactly the same. For instance, in your post you say the errors should always start and end with BUG: kernel NULL pointer dereference, address: blablabla Yet control+F in my syslog yields nothing of that kind. Same with __filemap_get_folio+0x98/0x1ff All I get is filemap_migrate_folio+0x1b/0x62 I've also read that I should remove certain plugins you mentioned. I'm however reluctant to do so as some, most notably appdata backup, are essential to backing up saves from the game servers I host. In your thread, is the top post updated with conclusions from further down the thread, or should I browse it to see if some plugins end up confirmed as culprits?

Hello, I have recently installed the binhex qbtirorrent-vpn docker container, and have been experiencing regular crashes ever since (around once a day). The system was perfectly stable previously, with un uptime of around 4 months. I believe I have narrowed down the issue to one mentioned in 6.12.4 and 6.12.6 change logs, related to MACVLAN calls. The problem itself is far beyond my knowledge level, but I have applied the fix suggested by Unraid in the change logs: I have switched "Docker custom network type" from MACVLAN to IPVLAN. Yet the crashes still occur, albeit with different errors in the logs. Therefore, here are my questions to those more knowledgeable than me: I have a Realtek RTL8125B 2.5G NIC on my motherboard, but it is not in use (not plugged in), as I use a generic chinese X520-DA1 10G NIC instead for connectivity, which has worked without issues for a year. The fix common problems plugin warns the RL8125B NIC is known to cause instability, and a plugin is available for an alternative driver. Can the Realtek chip cause instability even when it is not plugged in and not in use? Should I install the driver then? I have, to the best of my knowledge, applied the recommendations found here in the 6.12.4 changelog. Yet the crashes still occur. Please find attached the syslog of the latest crash, as well as the diagnostics obtained just after reboot. The syslog is full of errors related to "call trace" and "khugepaged Tainted", which is why I believe it is related to the MACVLAN call traces issue. What should I do next to attempt to fix the issue? Thanks in advance for your help, and I wish you all a (soon to be) happy new year! tower-diagnostics-20231231-1113.zip tower-syslog-previous-20231231-1012.zip

Oh wow, I'll definitely check this out later today, thanks! Edit: works like a charm so far! 100%. Only posted to report back as promised with the Windows event viewer: if there's memory issues on both OSes, it doesn't take rocket science to figure out the the server app from the devs is the problem. Thanks again!

Got it. It's just a bit frustrating since my saves are backed up at 4am every day, and the server often fails to restart properly; meaning that pretty much every single day I have to manually restart the server one or up to a dozen times until the port checks go through. Unfortunately for me it's the majority of the time, about 2 in 3 starts. I'm curious as to what could cause that variation. Couldn't find any information from people having this issue; so either the sample size is too small for there to be debate on the subject, or I'm really unlucky and it hits me harder for whatever reason. I remember from some posts for another game server, that game had an option to skip the network checks - a sort of "I know it works, I don't need you to tell me if it doesn't" option. Is the port check a part of the SOTF server client itself, or something added on top that could be disabled? On a side note, it seems you were right about Icarus. I finally had the time to run the Windows native server client to see if it memory leaked like the Wine variant in your docker container. And... well... I guess the event viewer speaks for itself: Averaging a modest ~20K "Ran out of memory" errors per day of uptime. So the server client itself has issues. I don't know what's the difference between Windows and Linux (specifically Unraid) that causes the latter to crash and not the former. Then again, the Windows client never crashed with an "Out of memory" log error like the docker, but my guinea pig collegues on the server did report getting repeatedly kicked out, but with no error reported in the logs. Last point, you're also probably right that the Icarus docker command you explained to me earlier is a "dirty" fix. I've had unexplained crashes where the whole Unraid OS seizes up (unreachable dashboard, frozen terminal via HDMI, requiring hard reset), ONLY when I apply that command. Syslog shows up empty of anything that could explain it. By process elimination I assume it has to be that command, do you think it could be the cause? Anyways, thanks again for the help and explanation!

Hello, I'm having a recurring issue with the Sons Of The Forest docker, where it gets stuck in the port verification stage. It'll try to test the ports to see if they're open (it sees they are), and just hangs there. It happens about 2/3 of the time and can take up to a dozen restarts for it to launch succesfully. Stuck at port 8766: #DSL [Self-Tests] [Config] Dedicated Server configuration file is valid. #DSL [Self-Tests] [Networking] Testing public accessibility... src\clientdll\steamengine.cpp (3003) : Assertion Failed: Attempt to call interface with invalid hSteamUser /+/ 1, appid=1326470, hpipe=131073, inprocess, thread=472 src\common\interfacemap.cpp (890) : Assertion Failed: IPC call to IClientHTTP::ReleaseHTTPRequest returned failure code 12 #DSL [Self-Tests] [Networking] Testing server ports against public ip <My IP>... #DSL [Self-Tests] [Networking] UDP GamePort [8766] is open. Stuck at port 27016: #DSL [Self-Tests] [Config] Dedicated Server configuration file is valid. #DSL [Self-Tests] [Networking] Testing public accessibility... src\clientdll\steamengine.cpp (3003) : Assertion Failed: Attempt to call interface with invalid hSteamUser /+/ 1, appid=1326470, hpipe=131073, inprocess, thread=464 src\common\interfacemap.cpp (890) : Assertion Failed: IPC call to IClientHTTP::ReleaseHTTPRequest returned failure code 12 #DSL [Self-Tests] [Networking] Testing server ports against public ip <My IP>... #DSL [Self-Tests] [Networking] UDP GamePort [8766] is open. #DSL [Self-Tests] [Networking] UDP QueryPort [27016] is open. What's strange is that when I try to host the server on a Windows VM or on my native Windows PC, it runs through the port checks 100% of the time. Moreover, in the docker, once it's up, it's rock solid connectivity wise. Both the Unraid server and my desktop are wired identically through an SFP+ switch which is itself hooked up to the router via SFP+. All this leads me to believe that it can't be the router. It's always either port 8766 (GamePort) or 27016 (QueryPort). Any ideas? Thanks in advance!

I might have an idea; there's a memory leak while running a specific game server through wine in a docker container, and I've had to run a command provided by ich777 to remedy it: but he did warn that he didn't like this solution, and might cause instability. That's the only variable I can think of. I've never encountered a crash without an explanation in the logs before otherwise. I'll turn this fix off, and see if it still crashes.

Hello again @strike I've encountered another crash with my server. The config file was correctly created, yet the crash still occurred. The Unraid UI failed to connect, and I had no video output on HDMI for the server as of today August 17th 10h45 (10:45 am). I checked the syslog mirrored to flash, and I can't find any error that would explain the crash. I'm posting the syslog and new diagnostics as an attachment in case anyone here might be able to help me figure this out. syslog tower-diagnostics-20230817-1124.zip

Thanks for the in-depth explanation. Like I said, I'm in over my head on this, and just relaying my understanding of the conversation on the dedicated server discord, hoping it can be useful to someone else down the line. Sorry if my comment sounded accusatory/expected you to fix this, because that's not what I intended. I'm pretty damn sure everyone here appreciates your work, knowing you owe us nothing, especially by working for free. It's just easy to see everything as a solution when beginners like me don't know what they're doing; I can see how that can get frustrating quick. What's at my level however, is trying the dedicated server bare metal on my PC to see if I encounter the same behaviour. Regardless, thanks again for taking the time to answer and set the story straight, much appreciated!

@ich777 Hello again, I'm back with updates on the Icarus server! I've had smooth sailing with the commands you provided, until today, where I encountered this error in the Unraid syslog: Aug 14 15:37:15 Tower kernel: __vm_enough_memory: pid: 3103, comm: IcarusServer-Wi, no enough memory for the allocation I consistently had ~30GB physical memory free available at all times. So it seems you were right about this being a "dirty" fix which could cause issues. Users far more knowledgeable than me on the Icarus discord are pivoting to waiting for a fix to the memory leak on Wine's end in an update. Could you tell me what version of Wine is being used in the Icarus docker you created? I can't seem to find that information by myself. If other users can confirm that Wine updates fix the OOM issue, is this something that could be updated on your end so the docker uses more recent versions of Wine? Thanks in advance!

Understood. I've run the command and rebooted, and rebinded the iGPU to Plex and Jellyfin, as well as reinstalled Intel GPU Top to monitor. I'll report back in a bit once I see how it goes. On a side note, does Unraid have an issue tracker of some sort? A place where I can follow a specific issue to see if it's resolved, rather than reading every single release note?

No, I haven't seen this before; I'll try it now! Is this a permanent change, or a command I'd have to type in after every reboot?

Hello, I've recently susbscribed to Plex Pass and installed Jellyfin to compare options and make up my mind on which I want to keep as my media server. I've had no issues using hardware transcoding in both Plex Pass and Jellyfin. Additionally, I've installed Intel GPU Top and the GPU statistics plugin to confirm hardware transcodingg was indeed being used, through the "intel_gpu_top" command. As soon as I did this, I've experienced crashes that I'd notice because Plex and Jellyfin clients couldn't connect to my server. I'd hop on to the Unraid GUI, and it too would be unable to connect (the login screen doesn't appear). Hopping on the server itself connected to a monitor through HDMI on the iGPU, the image would either be frozen, or filled with pink and green artifacts. With no way to control the server, it being seemingly bricked, a hard reset is necessary each time. I have read up on possible causes, and I've come to this thread, and my symptoms seem to be similar. Indeed, I did not have to be actively playing media to cause a crash: I regularly watch shows flawlessly in the evening and wake up with the system bricked in the morning; sometimes the system hangs minutes after it boots, without having the time to play any media back. I've tried removing the additional command from Plex and Jellyfin assigning the iGPU to them, as well as removed the "Intel GPU Top" and "GPU statistics" plugins from my setup. This appears to have, for now, resolved the issues. I cannot comment with certainty as I'd have to leave the system on for longer to confirm, but I didn't want to wait until then to post. TL;DR: Using the Intel iGPU eventually always crashes my system. Obviously doing without hardware transcoding is far from ideal, and negates the point of having an Intel build to begin with. So what are my options at this point? I've scoured the thread I linked, and I couldn't really find a solution, or at least one I understand and have been able to deploy. Quick info: CPU is an Intel i3 - 10100 running on a Z490-A Pro mb, with 48GB of RAM ( 2 x 8 + 2 x 16). Plex + Jellyfin appadata run off a healthy NVMe-cache. I've attached system diagnostics as well as a syslog (mirrored to flash). To avoid wasting your time, in the syslog, example crashes occured at 21h48 (9:48 pm) and 22h02 (10:02 pm) on August 12th. Thanks in advance! tower-diagnostics-20230813-0958.zip syslog

I'm aware; I meant that in the sense that while Linux hosting through wine has no official support from the devs, even the Windows instance of the dedicated server is still technically in beta. And as you said they seemed to have struggled to get this far to begin with. Got it, thanks! You're probably right, it's wishful thinking. I've been thinking about migrating all my game servers to a Windows VM with a proper server manager GUI like WindowsGSM or similar. But I can't deny the resource efficiency and convenience of docker containers with editable files shared through SMB. No worries, thank you for taking the time to answer my questions regardless! I now have a better understanding of the problem and what can and can't be done about it. Makes the whole thing a whole lot less aggravating once I manage to wrap my head around it.

It is the same issue; the slowdown and physics breaking is just an early symptom of the server running out of memory blocks. It crashes when it runs completely out, and kicks everyone out before restarting to recover. I get the exact same errors Ran out of memory allocating 0 bytes with alignment in the exact same circumstances as mentionned in the discussion and ReadMe, with more than 30Gb of spare physical memory available. No pressure, I understand; I can imagine it'd be a nightmare as a maintainer to keep track of, and troubleshoot, every baind aid fix - which may or may not work, when the real solution lies upstream with the game itself. From what I understand, even the Windows dedicated server is still in "beta". Commands worked as you explained, thanks! I'll do a quick test run that way, to see if this "fix" even works in the long run. Will it be reset if the docker container is restarted (not Unraid as you mentioned, but the docker container itself)? I back up the save files with the appdata backup plugin every night, and it restarts the game containers in the process. Either way, in the long run I think I'll just spin up a Windows VM if the issue keeps coming up, until the Icarus devs release a native Linux server client (there seems to be some demand for it), or adress the issue specifically. I'll take your word that this fix is far from ideal anyways, I'd rather not play around with things I don't fully understand! If you have the time and opportunity to do so though, I'd be curious to see if you can replicate the issue on your end. Intuitively, I'd imagine running out of memory blocks becomes more of a thing when the world grows larger (as players explore) and more populated (with structures, equipment and creatures). So it could take some time before the issue comes up.

I've had a week and a half of smooth sailing, good performance and no bugs; but just yesterday and today, the friends I host for reported massive slowdowns, physics not working, followed by being kicked out of the server. I've rebooted yesterday, thinking it was a one-off, but it occured again today after about 14 hours of uptime. So I've experienced the issue twice at this point. I saw no mention of your container by searching the thread. I don't know of a "semi official" docker, but the one with the fix in the ReadMe is a SteamCMD variant like yours. The discussion itself had a variety of users: desktop linux, hosting providers, some Unraid users. Interesting. Following the discussion, I was under the impression that no one had really run a stress test over time yet to determine if it was a flawless fix. But the people at Shockbyte are apparently testing this specific fix for their customers. Yeah, I was surprised too; it's strange that it ran fine for over a week, then it all came crashing down in the past few days. Maybe it has something to do with the world size growing as the clients keep playing.

Hello @ich777! There seems to be an issue with Icarus running on linux, where it runs out of memory blocks, causing the docker container to crash (OOM) and restart. The community seems to have found a fix however, but it's beyond my capabilities to apply it myself; so I thought I'd forward the issue. Icarus "Linux and Docker Support" discord thread discussing the issue. Fixed community docker hub page has a ReadMe at the bottom explaining the issue and the fix. Is this a fix that can be implemented on your end through the Docker Hub? Or is it something we have to implement on our end? If so, I'll finally have to sit down and learn how to edit docker files on Unraid. If I understand correctly, I can use the docker console to apply the fix, but it won't "stick" through updates unless I edit the dockerfile itself? Regardless, thanks for taking the time and effort to put out all these containers and make life simple for the rest of us! Much appreciated. TL;DR: Those who have issues with the Icarus Docker crashing with a "Ran out of memory" error, it's a known issue with the dedicated server running out of memory blocks. Community seems to have found a fix, which you can find in the links above.