Native Linux server (with management scripts)
- Thread starter Alloc
- Start date
FeistyLemur
New member
I have the same issue.
363156 build is installed, when I connect it tells me it's v9.0 and I can't get in. I tried making a new test instance, no help.
363156 build is installed, when I connect it tells me it's v9.0 and I can't get in. I tried making a new test instance, no help.
FeistyLemur
New member
What a day for an update to come out.
I just got the power supply and cooler I needed for my spare parts to get my testing server moved over to new hardware. So I was all excited to see how it performs. I had an intel 6 core 980x gulftown system that was just missing a few things and now it's all loaded up and running.
I'm so eager to see how it performs.
I just got the power supply and cooler I needed for my spare parts to get my testing server moved over to new hardware. So I was all excited to see how it performs. I had an intel 6 core 980x gulftown system that was just missing a few things and now it's all loaded up and running.
I'm so eager to see how it performs.
Leviathan5
New member
What app id do I use to install the dedicate version of the game?
G
Guest
Guest
Danke Alloc für dieses tolle Server-Tool. Benutze es zwar erst seid 9.0 doch lنuft es prima und auch die erklنrungen in deinem Wiki sind gut.
Aprobs 9.1 lنuft mit den REV. 127 .dll Datein auch wieder.
Aprobs 9.1 lنuft mit den REV. 127 .dll Datein auch wieder.
Hi!
I have the Linux server running on a machine at home, and it's working fine. I did however try to get this up and running on a Google Compute Engine, but my client gets stuck at "Waiting for server...". I've opened UDP ports 25000-25003 and in the 27xxx range. I can see it in the server list. I had this problem with the Alpha 8.8 too, when I last tried it a couple of weeks ago, so it's not something specific to Alpha 9.1.
In the server logs I can see that I can connect at least, because it says "GMSG: jomomomo joined the game". When running "7dtd.sh status MyInstance" it says "0 players" however.
I've tried the "Disable NAT" setting as both true and false. I guess it's some network setting I've missed, or something Google is blocking, but I really don't know what to try next.
Any ideas?
I have the Linux server running on a machine at home, and it's working fine. I did however try to get this up and running on a Google Compute Engine, but my client gets stuck at "Waiting for server...". I've opened UDP ports 25000-25003 and in the 27xxx range. I can see it in the server list. I had this problem with the Alpha 8.8 too, when I last tried it a couple of weeks ago, so it's not something specific to Alpha 9.1.
In the server logs I can see that I can connect at least, because it says "GMSG: jomomomo joined the game". When running "7dtd.sh status MyInstance" it says "0 players" however.
I've tried the "Disable NAT" setting as both true and false. I guess it's some network setting I've missed, or something Google is blocking, but I really don't know what to try next.
Any ideas?
FeistyLemur
New member
So I've been trying to restart my instance periodically using systemd timers in arch linux. I'm kind of at a loss as to what I'm overlooking though.
I put a restart script in /usr/local/lib/7dtd/ called restart<instancename>.sh which consists of the following.
#!/bin/bash
. /usr/local/lib/7dtd/common.sh
telnetCommand <instancename> "say Server will restart in 5 minutes"
sleep 60
telnetCommand <instancename> "say Server will restart in 4 minutes"
sleep 60
telnetCommand <instancename> "say Server will restart in 3 minutes"
sleep 60
telnetCommand <instancename> "say Server will restart in 2 minutes"
sleep 60
telnetCommand <instancename> "say Server will restart in 1 minutes"
sleep 60
telnetCommand <instancename> "say Server going down for restart now!"
sleep 10
/usr/local/bin/7dtd.sh kill <instancename>
sleep 20
/usr/local/bin/7dtd.sh start <instancename>
If I run this script from bash it works fine, however, when I invoke it with systemd.timers it all runs, but the server simply doesn't start back up, even though it reports success in the systemd unit.
this is the unit itself which ive been invoking on a timer.
[unit]
Description=Restart game server.
[service]
Type=oneshot
ExecStart=/usr/local/lib/7dtd/restart<instancename>.sh
It runs, the server shuts down, it reports success and shows successful output in the status log for the unit, but the server just isn't running after. Yet if I run the script myself from bash it works perfectly.
I'm not an expert with systemd but any idea what it is I'm missing?
I put a restart script in /usr/local/lib/7dtd/ called restart<instancename>.sh which consists of the following.
#!/bin/bash
. /usr/local/lib/7dtd/common.sh
telnetCommand <instancename> "say Server will restart in 5 minutes"
sleep 60
telnetCommand <instancename> "say Server will restart in 4 minutes"
sleep 60
telnetCommand <instancename> "say Server will restart in 3 minutes"
sleep 60
telnetCommand <instancename> "say Server will restart in 2 minutes"
sleep 60
telnetCommand <instancename> "say Server will restart in 1 minutes"
sleep 60
telnetCommand <instancename> "say Server going down for restart now!"
sleep 10
/usr/local/bin/7dtd.sh kill <instancename>
sleep 20
/usr/local/bin/7dtd.sh start <instancename>
If I run this script from bash it works fine, however, when I invoke it with systemd.timers it all runs, but the server simply doesn't start back up, even though it reports success in the systemd unit.
this is the unit itself which ive been invoking on a timer.
[unit]
Description=Restart game server.
[service]
Type=oneshot
ExecStart=/usr/local/lib/7dtd/restart<instancename>.sh
It runs, the server shuts down, it reports success and shows successful output in the status log for the unit, but the server just isn't running after. Yet if I run the script myself from bash it works perfectly.
I'm not an expert with systemd but any idea what it is I'm missing?
Last edited by a moderator:
FeistyLemur
New member
There are output logs at the time and they have a ton of errors about being unable to load the libraries from /home/sdtd/engine/
Presumably thats where the server fails to come back up? The script thinks the job is done and reports done! to systemd, I've even managed to get the instance to appear to be running I can even see my server on the browser but it fails to connect and then I go back to the terminal and check and now it's not running.
A bunch of these errors...
2014.08.25 18:33:45: Fallback handler could not load library /home/sdtd/engine/7 DaysToDie_Data/Mono/x86/SteamworksNative
2014.08.25 18:33:45: Fallback handler could not load library /home/sdtd/engine/7 DaysToDie_Data/Mono/x86/SteamworksNative
I'm pretty sure that was one of the start attempts I was making with the timer unit. I'll have to try again this evening to be sure I'm looking at the right log though, as there are quite a few of them in the folder.
I'm guessing it's some kind of issue with user and permission maybe? I tried adding user=root to the unit that starts the script but that was no help.
I did write a proper systemd start unit that works very well to start and stop an instance last night, so at least that much is working good now. I guess I'll play around with that more tonight if I can.
Alloc,
I found that if I issued: buff blah
the server spits back (repeatedly and unending), "Exception: Buff named 'blah' does not exist!'
Reconnected to telnet and the server is still spewing the error. I couldn't issue a shutdown so I had to kill the process.
Great package, by the way
MobiuS
I found that if I issued: buff blah
the server spits back (repeatedly and unending), "Exception: Buff named 'blah' does not exist!'
Reconnected to telnet and the server is still spewing the error. I couldn't issue a shutdown so I had to kill the process.
Great package, by the way
MobiuS
qriff
New member
With latest versions, in current_output.log, now receiving:
This has apparently been manifesting earlier as daemon crashes but without error messages (or lost) and now failing to start (on Debian, latest).
Fix, insert/raise http://unix.stackexchange.com/a/85458 in /etc/security/limits.conf from default of 4096 with:
Note: Relogin required!
Diagnostics: http://www.cyberciti.biz/tips/linux-procfs-file-descriptors.html
Code:
2014.08.27 10:47:58: [b]Error in Allocs telnetListenThread: Too many open files[/b]
2014.08.27 10:47:58: Stack Trace: at System.Net.Sockets.Socket.Accept () [0x00000] in <filename unknown>:0
2014.08.27 10:47:59: at System.Net.Sockets.TcpListener.AcceptTcpClient () [0x00000] in <filename unknown>:0
2014.08.27 10:47:59: at AllocsNetTelnetServer.telnetListenThread () [0x00000] in <filename unknown>:0
Code:
# 7dtd.sh status one
Instance: one
Status: Running
Open ports:
25000 (udp)
25001 (udp)
25002 (udp)
27036 (udp)
37720 (tcp)
8081 (tcp)
/usr/local/lib/7dtd/[b]common.sh: line 186: 5231 Killed[/b] nc 127.0.0.1 $TEL_PORT 0<&3
Players:
Game info:
Server name: One
Password:
Max players: 64
World: Random Gen
Network info:
Port: 25000
Public: true
Control Panel: off
Telnet: Port 8081, Pass
Code:
sdtd hard nofile 16384
sdtd soft nofile 8192Diagnostics: http://www.cyberciti.biz/tips/linux-procfs-file-descriptors.html
Last edited by a moderator:
Heh, thanks for the detailed report (and even a fix to it ).
7dtd is doing some bad stuff, especially at startup when it opens lots of files. And in one of the server fixes releases I even increased that problem (I think that's the one still shipped with the scripts)
I will release a new package in the next hours which hopefully also eliminates the problem for now.
).7dtd is doing some bad stuff, especially at startup when it opens lots of files. And in one of the server fixes releases I even increased that problem (I think that's the one still shipped with the scripts)
I will release a new package in the next hours which hopefully also eliminates the problem for now.