seductiveMango Posted April 12, 2022 Share Posted April 12, 2022 This might be a bit of a big one, I'll try to get markdown functioning so outputs are easier to read. Here we go. I've run a 7 days to die server for my friends and I for a while now off a 2016 macbook pro that I threw 20.04 server onto. Recently, we started noticing some lag so I figured I'd get my secondary desktop up and running as a dedicated server for this use. I followed the same steps, threw on ubuntu 20.04 server lTS, ran through the 7 days install (One of the steps is backwards, you have to force_install_dir before you log into steam) and ran the ufw rules. Now, I can't access the server even on my local network. When I run the server from my laptop, I get a nice netstat output of: root@macbook-server:/home/miles# netstat -tnlp | grep LISTEN tcp 0 0 127.0.0.1:8081 0.0.0.0:* LISTEN 1545/./7DaysToDieSe tcp 0 0 0.0.0.0:26900 0.0.0.0:* LISTEN 1545/./7DaysToDieSe tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 827/systemd-resolve tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1068/sshd: /usr/sbi tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 961/cupsd tcp6 0 0 :::22 :::* LISTEN 1068/sshd: /usr/sbi tcp6 0 0 ::1:631 :::* LISTEN 961/cupsd which is what I expect, we're listening on 26900 and 8081 (the actual port for the game and a telnet port for graceful shutdown). Problem is, when I do the same on the new server I don't get the 26900 listen. Just the 8081: root@serverboi:/home/server/7days/7DaysToDieServer_Data# netstat -tnlp | grep LISTEN tcp 0 0 127.0.0.1:8081 0.0.0.0:* LISTEN 1799/./7DaysToDieSe tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 660/systemd-resolve tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 788/sshd: /usr/sbin tcp6 0 0 :::22 :::* LISTEN 788/sshd: /usr/sbin There is still some small chance that this is the server not starting up correctly but I've diff'd successful startup logs with ones from the new server and they seem to be booting up fine, no extra errors. My ufw rules on both computers are: Status: active To Action From -- ------ ---- 26900:26905/tcp ALLOW Anywhere 26900:26905/udp ALLOW Anywhere 22/tcp ALLOW Anywhere 26900:26905/tcp (v6) ALLOW Anywhere (v6) 26900:26905/udp (v6) ALLOW Anywhere (v6) 22/tcp (v6) ALLOW Anywhere (v6) I ran some tests with opening netcat ports and talking over 26900 and it worked fine. My guess here is that somehow the server isn't actually starting up the listen port for some reason. Both servers are using the same exact config file. Both servers are starting the server from a local user (not root). They are both running ubuntu 20.04 LTS (although the macbook was updated from 16.04 to 20.04 when I went to run 7 days servers on it). Any help is much appreciated and I'd be glad to post anything else anyone needs. Link to comment Share on other sites More sharing options...
Beelzybub Posted April 12, 2022 Share Posted April 12, 2022 Try moving your second server's port to 26906. Also, what is your router doing as far as natting? If you use 26906 you'd need TCP 26906 and UDP 26906 - 26909 opened to your server's ip in your router. Link to comment Share on other sites More sharing options...
seductiveMango Posted April 12, 2022 Author Share Posted April 12, 2022 Second server was off for these. This is all local so no routing is occurring. Link to comment Share on other sites More sharing options...
meganoth Posted April 12, 2022 Share Posted April 12, 2022 Did you check if the server is running? If it is, use "lsof -p <PID>" to list its open files and ports. Link to comment Share on other sites More sharing options...
SylenThunder Posted April 12, 2022 Share Posted April 12, 2022 I did notice something a bit off with that guide. It's having you open way more ports than you need to. sudo ufw allow 26900:26905/tcp sudo ufw allow 26900:26905/udp Should actually be sudo ufw allow 26900/tcp sudo ufw allow 26900:26903/udp I find some other information in that guide to be a bit overly simplistic, and probably isn't good to follow long-term. I would strongly recommend using something like LGSM, or Allocs Scripts instead. Especially if it's going to be something more than a server you just turn on occasionally for a couple of buddies. Link to comment Share on other sites More sharing options...
seductiveMango Posted April 13, 2022 Author Share Posted April 13, 2022 Thank you! I'll edit down the open ports. The problem has somehow fixed itself? I removed and reinstalled 7 days (following the same order of operations) and now it happily starts up it's port. I'm trying to figure out what was actually wrong so that I could post a more helpful answer here in case someone else has this happen but honestly I have no idea. To answer what was here: Yes server was for sure running. You could even see it open the telnet port but not the main port. Server got up and running last night, we ran a deshong tower in it to put it through its paces and my god upgrading from a macbook pro to this was a game changer. Edit for more clarification on how I fixed for anyone who'd need: rm -rf ~/7days rm -rf ~/.local/share/7DaysToDie Then ran through the install via steam client again. Manually edited config files rather than copy pasting ones I already had. Link to comment Share on other sites More sharing options...
FinkPloyd Posted April 16, 2022 Share Posted April 16, 2022 On 4/13/2022 at 11:58 PM, seductiveMango said: Manually edited config files rather than copy pasting ones I already had. Might be due to the differences in end of line characters used in versions of the OSs. Link to comment Share on other sites More sharing options...
meganoth Posted April 20, 2022 Share Posted April 20, 2022 Mmh, could this also be a result of the two new lines added to the serverconfig.xml in alpha20.4. You never told us the versions of the game you had installed. Anyway if you want to search for causes you definitely should look into the logfiles. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.