Alloc

Well, you kinda got your culprit there ... seems to be a deeper issue with your system / Unity. It doesn't even get *close* to the game code itself. What CPU do you run? If VM both host as well as the virtualize CPU type.

Try to run the process manually as palmic pointed out.

It's on my list already. Yeah, that has been reported before, so far wasn't able to repro that myself though. Steam fiddling with the mods-folder is the best guess so far though.

Hm, never had that happen with OOMs. Other causes my obviously leave a process running but unusable. Some people wrote nice little scripts for detecting this though. Logs? stdout.log, output_log ... anything?

Theoretically: Sure. Currently I don't have the required data at hand though and it's thus also not possible to query it from the web page.

The fixes are part of the server process, they can't do anything like that. The scripts on the other hand could but as there's not even a guarantee to what shows up in the log on such occasions it doesn't make a lot of sense either. Easiest is still just creating a cron job that regularly "starts" the server as it will only do anything if the server is actually no longer running. Something like that might be possible as an option in the future. Combined with a warning to the user this actually sounds quite interesting

The actual error is in line 103. No idea why this is happening though, might be related to the still unknown occasional crashes on Unity 5.2.* builds on Linux. Sorry, no further idea right now. But at least it will most likely get better with A14 That's because the backup (done by rsync) uses hard links. Basically all files that are identical between two (or more) consecutive backups share the same disk area that's why the total backup size doesn't increase as much as it would with all new copies each time This is indeed not critical for the most part (worst case you might lose some of the player map exploration progress) and definitely won't cause any stability issues with the server. Most likely related to the OOM later on. Probably not dramatic either but we'll have a look. First line: "Anti-cheat" detection of my mod (player probably used an exploit or just happened to stumble on a bug so he got a stack of an item with a stack size that's not achievable normally). "Couldn't send": No harm, player disconnected so the server couldn't send some data. This is where it starts to get completely irrelevant: If there's an OOM everything after that is basically just random and the server's no longer in a stable state (and typically crashes at the same instant). What the info line shows is just Mono's heap but Unity uses some more resources for it's native stuff so you were more likely at 3.5 GiB or something and typically the limit for 32 bit processes is somewhere around 3.5 to 3.8 GiB. Could have amplified the problems but in the end it's just hitting the memory limit for whatever reason after some playtime Regards, Chris

That's interesting ... Can you post / send me a full log of both 32 bit (running fine) and 64 bit (with that error)?

It's control panel port + 2, not telnet + 1. So you probably got CP port on both set to the same and this it can't open the port on the second instance for listening as it says in the log

No, it's directly served, you can edit it at any time as it's currently not cached. Yeah, but you will either have to reverse proxy the API / map requests to the game or modify the files so they access the API / map from a different location (the game server). Yeah, the server, but the 7dtd server process most likely is not (that is unless you modified the scripts to start as 64 bit).

Have you been monitoring the memory consumption / size of the virtual address space of the process? If you don't get this soon after starting the server but only later on when people have played on it and you only access the web panel after that for the first time it is probably just a memory issue. Ah, ok, gotcha. Yeah, of course this could be done. But I don't see that much of an audience that would benefit from this. Or maybe there would be in terms of server managers or something. Would require a lot of extra time though But of course it's open to everyone to have a go at implementing something like that Yeah, probably a good idea. Heh, no issues there As I said above though ... this would just add another layer of work on my end while not giving any benefit to the integrated web panel. Of course it sounds like a good idea but I suppose someone else will have to have a go at this. As has been said a few times these pages: 32 bit is fully working, 64 bit not (probably only the serverlist part, but haven't looked any further). No, it's not used. Suppose the server isn't usable at this moment anymore? Probably plain crash (or at least hangup) due to the memory restrictions. 15 slots sounds a bit much for a 32 bit server instance.

Navezgane: Possibly. RWG: Possibly one to specify an area (infinite world can't be "all" rendered).

Are you running any mods on that server? Especially additional items / item icons? No idea why it would crash in the destroy method unless it's already having memory issues at that point. You mean like the API it already has and the web frontend uses to get the required data? Nothing ever changed on the Linux scripts regarding the started executable. It's directly invoked the .x86 executable since the very first release for the native Linux 7dtd build on 2014-06-02. You either edited the scripts start-script or you didn't use my scripts to start the server or you never actually ran the 64 bit build

Ticket 60 is referring to the Linux scripts though, no relation to the mod I don't. I don't even use VS. I doubt that it's possible to attach a .NET debugger to a non-development build of the game though. For me it's typically writing code and if something does not work adding a few log prints where applicable.

Nah, no real plan. Most likely the first thing would be finally fixing the log tab No reason why not, just gotta find a place to save this stuff Also it's core game so will take longer to hit public anyway. Kinda ... I want to do them but especially the scripts have quite low priority currently as they worked as required mostly. Like some of the other "chat" things I wanted to delay it until I reworked the chat system / logging in game so it's easier to parse that stuff from the log.

The output regarding the certificate is "normal" behaviour. Also doubt the webserver part itself is directly responsible for the crash, more likely some sideeffect in combination with the core code or just something simple like OOM. Did you have a look at the *top* of the log file? Depending on what's causing problems the Linux client sometimes overwrites the content there with error messages. I guess the line breaks are broken in this copy? Otherwise the whole exec of the server would be commented out That's definitely weird. Just tested over here and starting the 64 bit build will definitely output "Build: Linux 64 Bit"

Yeah, weird ... You could either try debugging the script (e.g. adding some echo's to see where it's going and what it's doing) or just remove the if-stuff for platform detection altogether. But it will most likely not show up in the server browser then

Yeah, the question was targeted to Sylen to see if it indeed does return the expected value on his machine

What does "uname -m" return?

Yep. Yes and no The connection is a simple TCP connection, there's no "random" ports for outbound vs inbound traffic. Of course any TCP connection (at least normally) does use a random client side port but that doesn't impact anything. No estimate. Hope to get dev speed up a bit in the upcoming weeks though as I can dedicate more time to it.

Well, yeah, you are running the 32 bit server

Neither nor. It's anon downloadable since two days ago The 64 bit server shows in the browser? Can you post the log of your server? (First ~1k lines should be enough).

Scripts are Apache 2.0 now, mod will follow later on.

If you're talking about a WebAPI for console commands: Not yet. Hell NO Wouldn't want to get that kind of PITA in to the game If you want code to handle your own requests you'll have to write .NET code for the mod. If you're talking about the game's original control panel: Yeah, it's not very fault tolerant. Based on a OTP for the next request received on each prior request. As long as you keep a strict order of issuing things this should work (at least one server manager used to support this interface) though. If you can't connect to remote ports with PHP (open a simple outgoing TCP socket) you'll either have to wait until I add the command API or code something yourself But it should be possible to open connections at least to some ports, did you try changing the "Telnet" port on your game server to something like 80? How should that work? If a program has run out of memory there's no way to catch that anymore, it's already crashed.

Kinda ... but to the *if*-part ... of course it's not updating now as it only uses the else-part once for each player