Native Linux server (with management scripts)

Hello friend :) ... Have updated the script and cleaned the player.xml file. But the error message continues.

Hm, might be the same problem as I saw before ... I assume you are using a version of the scripts prior to v.22? If so please update and delete the players.xml (or at least clean it up manually).
Might also be related to the Telnet thread having crashed. Will try to add some checks in there.

/EDIT: Nope, should not be a problem ;)

Regarding Q2: I think this only happens when the Telnet thread crashed so shutdown does not work. Can't do anything about it as that's a bug in the game itself.
Click to expand...
 
Linux server with no scripts

I'm trying to run a dedicated server but without the custom management scripts. My reasons for it are: I'm on a Gentoo box (64bit), not a Debian system; I want to adhere to the same workflow I have set up for other dedicated servers; I will only want to run one instance of the 7dtd server.

I did initially try out the steps laid out at https://7dtd.illy.bz/ , adapting for the differences in my system but it failed when I got to the start-stop daemon. I wasn't too surprised about that since I'm using Gentoo. I tried to start the server manually straight out of the engine folder but it failed (see below code tag). After this, I removed all the files I installed following the guide.

So I started a fresh install following my own dedicated server setup with steam. I installed the windows 7dtd files with steam at '/srv/sevendaysd/server', downloaded 'http://illy.bz/fi/7dtd/linux_files.tar.gz', and made sure the 32bit SteamworksManaged.dll was in 7DaysToDie_Data/Managed. I was unsure what to do with the Linux engine files since the engine/ folder appears to be the install root, my '~/server/', and there are other files outside that directory in the arachive. I just merged the engine files with my '~/server/' and put the extra lib*.so in there too.

When I run 7DaysToDie.x86 I am greeted with:

Code: 
Set current directory to /srv/sevendaysd/server
Found path: /srv/sevendaysd/server/7DaysToDie.x86
Mono path[0] = '/srv/sevendaysd/server/7DaysToDie_Data/Managed'
Mono path[1] = '/srv/sevendaysd/server/7DaysToDie_Data/Mono'
Mono config path = '/srv/sevendaysd/server/7DaysToDie_Data/Mono/etc'
and a closed port 25000.

So I adapted the 'startdedicated.bat' to 'startdedicated.sh', ran that, and got the same results.

I don't know what's going on under the hood here and why it isn't working. Unfortunately for me, the only Linux dedicated server tutorials are for this management script setup which neither works on my system nor do I want to use it.

Any help would be appreciated.

 
That output you posted is the normal one you get when you start up 7dtd.

I would still suggest using the scripts, start-stop-daemon should not be a problem as I included the required source in the archive just for this purpose. If there's something wrong with compiling it we can figure it out together ;)

 
Thank you for the quick reply. I will go ahead and give the tutorial another go with as few alterations as possible (except Gentoo) and try to figure out what went wrong with the start-stop daemon step. My end goal is to not use the scripts (I have a list of reasons) but I would like to thank you for providing them to the community. I'll let you know if I encounter any problems with the start-stop daemon I cannot solve. I did not troubleshoot when I last tried since I expected it to not work before I started.

 
Well, I redid the entire installation following your guide verbatim with the only exception being I did not add 7dtd.sh to the default run level. I did not run into any errors compiling the start-stop daemon this time. The test instance I created starts with the only reported error being shown when I ran `7dtd.sh instances list` the first time.

Code: 
Instance name        | Running  | Players | Port
---------------------+----------+---------+------
(UNKNOWN) [127.0.0.1] 8081 (sunproxyadmin) : Connection refused
TestInstance         |      yes |    8/25000 |     0
Despite that error, I can connect via telnet just fine.

Unfortunately, I am still unable to connect as port 25000 is still closed for some reason, even though the server is up and I can run commands on it via telnet. I'm not entirely sure what's up with that but I suspect it may be something specific to my system (yes, I checked my firewall).

EDIT: Or not. I changed the ports around and 7dtd still won't open the game port. I switched the telent port and the game port for testing and telnet runs just fine on port 25000 while 7dtd will not open port 8081. Not sure what to make of this.

 
Last edited by a moderator:
Well, I redid the entire installation following your guide verbatim with the only exception being I did not add 7dtd.sh to the default run level. I did not run into any errors compiling the start-stop daemon this time. The test instance I created starts with the only reported error being shown when I ran `7dtd.sh instances list` the first time.

Code: 
Instance name        | Running  | Players | Port
---------------------+----------+---------+------
(UNKNOWN) [127.0.0.1] 8081 (sunproxyadmin) : Connection refused
TestInstance         |      yes |    8/25000 |     0
Despite that error, I can connect via telnet just fine.

Unfortunately, I am still unable to connect as port 25000 is still closed for some reason, even though the server is up and I can run commands on it via telnet. I'm not entirely sure what's up with that but I suspect it may be something specific to my system (yes, I checked my firewall).

EDIT: Or not. I changed the ports around and 7dtd still won't open the game port. I switched the telent port and the game port for testing and telnet runs just fine on port 25000 while 7dtd will not open port 8081. Not sure what to make of this.
Click to expand...
You can look with netstat -l if there is anything else already running on the specific ports.

Do you have a firewall like iptables blocking incoming traffic?

 
You can look with netstat -l if there is anything else already running on the specific ports.Do you have a firewall like iptables blocking incoming traffic?
Click to expand...

...

(yes, I checked my firewall)

...
Click to expand...
It's set to effectively accept any packets from the internal LAN anyway. Besides, I would think that swapping the telnet and game ports would reveal something like the firewall blocking inbound connections (except I didn't realize earlier that the game uses UDP and not TCP which would make that last statement not true). Fortunately for me, I must have changed something somewhere along the way and it works. nmap wasn't helpful because it kept probing 25000/tcp and I didn't realize it wasn't probing udp by default as well.

Now the only problem I am trying to figure out is how the instances are started via the script that's different from my startdedicated.sh. I did a diff of the '/home/sdtd/engine/' and my '/srv/sevendaysd/server' and they are the same but when I start up my /srv/sevendaysd version, it spits out this:

Code: 
[s_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
[s_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.so.

...

Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
0.049 Could not initialize the native Steamworks API. This is usually caused by a missing steam_appid.txt file or if the Steam client is not running.
I noted that the LD_LIBRARY_PATH is set to the downloaded 'linux_files' directory containing the extra libraries that I didn't know what to do with originally, and the commands passed to an instance when it starts is different than those found in the provided 'startdedicated.bat' and mirrored my 'startdedicated.sh' accordingly. Despite this, I get the above errors. The steamclient.so is located in 'linux_files' which is in the library path so I find it a little odd that it cannot find it.

 
Well, I found the solution to my above problem. There was a trailing "\r" at the end of my 'startdedicated.sh' that stopped all the gears from turning because I copied and edited the supplied 'startdedicated.bat'. Now It starts and I can connect, though I get kicked with:

Code: 
Server disconnected you:

Reason: Your account 'SuspiciouslyAbsent' is not activated or no server answer!
Hopefully I can find a solution to that in time so I can just edit this post instead of having to triple post.

 
Thought I could edit my last post in time to add this. Here's some relevant info from the output_log.txt. It appears once right before I join the server and only when I go to join.

Code: 
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Fallback handler could not load library /srv/sevendaysd/server/7DaysToDie_Data/Mono/x86/SteamworksNative
Exception: ServicesGameServer.Initialize failed: SteamInitializeFailed
 at ManagedSteam.ServicesGameServer.Startup (UInt32 ip, UInt16 steamPort, UInt16 gamePort, UInt16 queryPort, ServerMode serverMode, System.String versionString) [0x00000] in <filename unknown>:0
 at ManagedSteam.ServicesGameServer.Initialize (System.Globalization.CultureInfo activeCulture, UInt32 ip, UInt16 steamPort, UInt16 gamePort, UInt16 queryPort, ServerMode serverMode, System.String versionString) [0x00000] in <filename unknown>:0
 at ManagedSteam.ServicesGameServer.Initialize (UInt32 ip, UInt16 steamPort, UInt16 gamePort, UInt16 queryPort, ServerMode serverMode, System.String versionString) [0x00000] in <filename unknown>:0
 at SteamMasterServer.Connect (UnityEngine.MonoBehaviour _mono) [0x00000] in <filename unknown>:0
 at GameManager.ᢵ▒~Y~C () [0x00000] in <filename unknown>:0
 at GameManager.Awake () [0x00000] in <filename unknown>:0
EDIT:

Solved, I think...

I think it has to do with running multiple instances of the server. I had left an instance running from when I did a vanilla install following Alloc's guide. Once I stopped that, I could connect to my server that wasn't using the management scripts.

 
Last edited by a moderator:
Well, from what I experienced it seems to work the same with no changes. Running multiple instances may not work, but I don't know if it did or did not work before.

EDIT: Oh, and the update to 8.7 may nerf your save game file so be sure to back it up first!

 
Last edited by a moderator:
I ran the script

/usr/local/bin/7dtd.sh instances updateengine

then created new game instance using new config template, played several minutes and it seems just fine.

However, since I'm new to 7dtd itself, I don't know whether the linux_files including "7DaysToDie.x86 engine" have to be updated or not.

As far as I know, the updateengine option updates only the game itself via steamcmd.

So, I re-downloaded and checked the linux_files that Alloc provided. Their timestamp are still 2 weeks ago, so there's no change at the moment.

Does anyone know where to get information about 7DaysToDie.x86? Is that the official one? If so, where can I get the latest build?

Anyway, this thread is very helpful. Thanks!

 
Well it does still work after updating the engine, but I guess it will need a script update to configure some of the newer 8.7 server stuff (though not much sadly)

 
Yes there are some changes needed. Keep calm Alloc will release them as fast as possible for him. :)

In general you can run the server scripts without any problems.

 
Regarding Alpha 8.7

The current version of the scripts will work with 8.7. Only things not working right now: Log parsing to get events like player (dis)connect logged etc. Also the two new config options are obviously not yet included in the instance editor. Will release an update for this within the next 12 hours.

There's no need to update anything else besides the game, the Linux specific files only change when TFP switch to a newer Unity version.

Well, from what I experienced it seems to work the same with no changes. Running multiple instances may not work, but I don't know if it did or did not work before.
Click to expand...
Did you test it and it did *not* work? Should work, so that would have to be checked :)

Does anyone know where to get information about 7DaysToDie.x86? Is that the official one? If so, where can I get the latest build?
Click to expand...
There's no "official" Linux binaries yet. Those are all provided by me so far and the latest is within the tar-archive linux_files.tar.gz, but that won't update as long as I do not announce so ;)

Well it does still work after updating the engine, but I guess it will need a script update to configure some of the newer 8.7 server stuff (though not much sadly)
Click to expand...
Only things changed AFAIK are the two new options: MaxSpawnedZombies, VACEnabled. Anything else changed?

New dedicated server build

I will also test if the new dedi build runs fine with the current stuff and then switch to using that one. That might take one or two days more though.

Regards,

Chris

 
Only things changed AFAIK are the two new options: MaxSpawnedZombies, VACEnabled. Anything else changed?
Click to expand...
Didn't seem like a whole lot added for servers :(

New dedicated server buildI will also test if the new dedi build runs fine with the current stuff and then switch to using that one. That might take one or two days more though.
Click to expand...
Maybe they should just hire you to make the dedicated linux builds :D seems like the entire area gets ignored or they don't have enough developers to work on more areas of the game.

 
Thank you all for answering such hasty-successive questions. Now that I grasped some part of the situation.

Knowing that, I want to thank you again, Alloc!

...well, I'd hosted a certain zombie MOD server, so I'm accustomed to waiting(nicely) for the devs! :)

 
Maybe they should just hire you to make the dedicated linux builds :D seems like the entire area gets ignored or they don't have enough developers to work on more areas of the game.
Click to expand...
Finally there is no much difference between the Windows and Linux dedicated server. Just the binary is different, which is delievered by Unity.

I think there are issues with the dependencies.

 
You must log in or register to reply here.
Back
Top