starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 14:15:59 +03:00

[GH-ISSUE #856] [sdtdserver] Server Abort after start #688

New issue

Closed

opened 2026-02-27 02:03:09 +03:00 by kerem · 16 comments

kerem commented

2026-02-27 02:03:09 +03:00

Owner

Originally created by @gotah on GitHub (Jun 2, 2016).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/856

Hello Everyone!

I have a problem with 7 Days To Die, server Crash after being started,
I'm running a Debian 8 (64)
here the output log
http://pastebin.com/gRJGYwpk
to me seems be an incompatibility between my mono version and unity, but I'm not sure
anyone can give me a hint ?
thanks!

Originally created by @gotah on GitHub (Jun 2, 2016). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/856 Hello Everyone! I have a problem with 7 Days To Die, server Crash after being started, I'm running a Debian 8 (64) here the output log http://pastebin.com/gRJGYwpk to me seems be an incompatibility between my mono version and unity, but I'm not sure anyone can give me a hint ? thanks!

kerem

2026-02-27 02:03:09 +03:00

closed this issue
added the
distro: Debian

game: 7 Days to Die
labels

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jun 2, 2016):

Hi,

Crash after "INF NET: Starting server protocols" ?
Maybe port already in use ?

@UltimateByte commented on GitHub (Jun 2, 2016): Hi, Crash after "INF NET: Starting server protocols" ? Maybe port already in use ?

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@gotah commented on GitHub (Jun 3, 2016):

Hi UltimateByte,

no ports are not used, just checked (netstat -a -n | grep 26900)

@gotah commented on GitHub (Jun 3, 2016): Hi UltimateByte, no ports are not used, just checked (netstat -a -n | grep 26900)

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@cedarlug commented on GitHub (Jun 3, 2016):

Could you post the output of ./sdtdserver details, removing any credentials in the output?

Also, why do you believe it's a mono/Unity issue - something specific in the log?

@cedarlug commented on GitHub (Jun 3, 2016): Could you post the output of `./sdtdserver details`, removing any credentials in the output? Also, why do you believe it's a mono/Unity issue - something specific in the log?

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@gotah commented on GitHub (Jun 3, 2016):

yes,
here is the details: http://pastebin.com/Jb23uxEc
I tried to run also ./7DaysToDieServer.x86_64 with the same commandline but the result is the same

I think is something mono/unity related because of the native stacktrace on top of the output log

`Native stacktrace:

/home/test/7DaysToDieServer_Data/Mono/x86_64/libmono.so(+0x91772) [0x7f7365d85772]
/home/test/7DaysToDieServer_Data/Mono/x86_64/libmono.so(+0x348a5) [0x7f7365d288a5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0) [0x7f73673588d0]
./7DaysToDieServer.x86_64(_Z17UpdateNetworkLoopPv+0x4e) [0x1338624]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4) [0x7f73673510a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f73665ec87d]`

full log here: http://pastebin.com/wuvZibSt

@gotah commented on GitHub (Jun 3, 2016): yes, here is the details: http://pastebin.com/Jb23uxEc I tried to run also ./7DaysToDieServer.x86_64 with the same commandline but the result is the same I think is something mono/unity related because of the native stacktrace on top of the output log `Native stacktrace: ``` /home/test/7DaysToDieServer_Data/Mono/x86_64/libmono.so(+0x91772) [0x7f7365d85772] /home/test/7DaysToDieServer_Data/Mono/x86_64/libmono.so(+0x348a5) [0x7f7365d288a5] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0) [0x7f73673588d0] ./7DaysToDieServer.x86_64(_Z17UpdateNetworkLoopPv+0x4e) [0x1338624] /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4) [0x7f73673510a4] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f73665ec87d]` ``` full log here: http://pastebin.com/wuvZibSt

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@cedarlug commented on GitHub (Jun 3, 2016):

I'd solve this issue first:
Mem: total used free
Physical: 15G 15G 170M
Swap: 513M 238M 275M

@cedarlug commented on GitHub (Jun 3, 2016): I'd solve this issue first: `Mem: total used free` `Physical: 15G 15G 170M` `Swap: 513M 238M 275M`

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@gotah commented on GitHub (Jun 3, 2016):

done

free -h
total used free shared buffers cached
Mem: 15G 12G 3.3G 257M 278M 4.7G
-/+ buffers/cache: 7.4G 8.3G
Swap: 513M 178M 335M

same problem it crash at:
2016-06-03T13:54:49 13.092 INF NET: Starting server protocols

@gotah commented on GitHub (Jun 3, 2016): done > free -h > total used free shared buffers cached > Mem: 15G 12G 3.3G 257M 278M 4.7G > -/+ buffers/cache: 7.4G 8.3G > Swap: 513M 178M 335M same problem it crash at: `2016-06-03T13:54:49 13.092 INF NET: Starting server protocols`

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@cedarlug commented on GitHub (Jun 3, 2016):

I'd still lean toward a memory ceiling issue.

The game fires up just fine on a newly-installed test. I just installed the same zero-full sdtdserver on Debian 8 with 8G of ram, and it looks like the engine eats up more than 3G to start up, 1.5G resident.

Are you running in a virtualized environment? What does "ulimit -m" show (run as the user test on your system)?

@cedarlug commented on GitHub (Jun 3, 2016): I'd still lean toward a memory ceiling issue. The game fires up just fine on a newly-installed test. I just installed the same zero-full sdtdserver on Debian 8 with 8G of ram, and it looks like the engine eats up more than 3G to start up, 1.5G resident. Are you running in a virtualized environment? What does "ulimit -m" show (run as the user test on your system)?

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@cedarlug commented on GitHub (Jun 3, 2016):

Another request:

Post the results of:

ldd /home/test/serverfiles/7DaysToDieServer.x86

@cedarlug commented on GitHub (Jun 3, 2016): Another request: Post the results of: `ldd /home/test/serverfiles/7DaysToDieServer.x86`

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@gotah commented on GitHub (Jun 3, 2016):

Hello!
I freed up more mem (8G) but is still not starting, is not a virtual env.

ulimit -m
unlimited

and

ldd 7DaysToDieServer.x86
linux-gate.so.1 (0xffffe000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf7729000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf770d000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf7703000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7593000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf754d000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7530000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf7383000)
/lib/ld-linux.so.2 (0xf7749000)

and

ldd 7DaysToDieServer.x86_64
linux-vdso.so.1 (0x00007fff819d4000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f37eb453000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f37eb236000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f37eb02d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f37eacb2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f37ea9b1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f37ea79a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f37ea3ef000)
/lib64/ld-linux-x86-64.so.2 (0x00007f37eb671000)

@gotah commented on GitHub (Jun 3, 2016): Hello! I freed up more mem (8G) but is still not starting, is not a virtual env. > ulimit -m > unlimited and > ldd 7DaysToDieServer.x86 > linux-gate.so.1 (0xffffe000) > libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf7729000) > libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf770d000) > librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf7703000) > libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7593000) > libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf754d000) > libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7530000) > libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf7383000) > /lib/ld-linux.so.2 (0xf7749000) and > ldd 7DaysToDieServer.x86_64 > linux-vdso.so.1 (0x00007fff819d4000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f37eb453000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f37eb236000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f37eb02d000) > libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f37eacb2000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f37ea9b1000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f37ea79a000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f37ea3ef000) > /lib64/ld-linux-x86-64.so.2 (0x00007f37eb671000)

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@cedarlug commented on GitHub (Jun 3, 2016):

This is looking like "Not an LGSM" issue at this point.

But what the heck -

Go for the full trace (which will be huge):
(as root)
apt-get install strace
(as user test)
cd ~/serverfiles
strace -f ./7DaysToDieServer.x86 -logfile /home/test/log/server/output_log__2016-06-03__13-18-27.txt -quit -batchmode -nographics -dedicated -configfile=/home/test/serverfiles/sdtd-server.xml 2>&1 | tee /tmp/fulldump.out
The output (in /tmp/fulldump.out) will be large, so perhaps zip it up and post it somewhere.

@cedarlug commented on GitHub (Jun 3, 2016): This is looking like "Not an LGSM" issue at this point. But what the heck - Go for the full trace (which will be huge): (as root) `apt-get install strace` (as user test) `cd ~/serverfiles` `strace -f ./7DaysToDieServer.x86 -logfile /home/test/log/server/output_log__2016-06-03__13-18-27.txt -quit -batchmode -nographics -dedicated -configfile=/home/test/serverfiles/sdtd-server.xml 2>&1 | tee /tmp/fulldump.out` The output (in `/tmp/fulldump.out`) will be large, so perhaps zip it up and post it somewhere.

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@cedarlug commented on GitHub (Jun 5, 2016):

Close?

@cedarlug commented on GitHub (Jun 5, 2016): Close?

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jun 5, 2016):

@cedarlug You just made me notice that the details command isn't displaying the "-/+ buffers/cache" form free -m, but the raw used RAM, including cached elements. That's something to fix.

@UltimateByte commented on GitHub (Jun 5, 2016): @cedarlug You just made me notice that the details command isn't displaying the "-/+ buffers/cache" form free -m, but the raw used RAM, including cached elements. That's something to fix.

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@gotah commented on GitHub (Jun 6, 2016):

Hello!

sorry for my answer delay, I was traveling.
the full dump is almost done (I will publish it today) I found out something interesting related to some virtual interfaces I have

@gotah commented on GitHub (Jun 6, 2016): Hello! sorry for my answer delay, I was traveling. the full dump is almost done (I will publish it today) I found out something interesting related to some virtual interfaces I have

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@gotah commented on GitHub (Jun 6, 2016):

Okey,
I solved it, as @cedarlug said it was not a LGSM problem.
you can see the last part of the strace here: http://pastebin.com/iCHBKNYY
for some reasons, the server try to bind itself on every interface I had on the server, especially sono old virtual interface of lo

write(1, "IP address: 127.0.0.1\n", 22) = 22
write(1, "IP address: 127.0.0.4\n", 22) = 22
write(1, "IP address: 127.0.0.5\n", 22) = 22
write(1, "IP address: 127.0.0.6\n", 22) = 22
write(1, "IP address: 127.0.0.7\n", 22) = 22
write(1, "IP address: 127.0.0.8\n", 22) = 22
write(1, "IP address: 127.0.0.9\n", 22) = 22

these interface aren't UP but still resident in interfaces file of debian, I had to comment them out and unfortunately reboot the server (networking restart was not enough)

thanks to everyone for the effort!

@gotah commented on GitHub (Jun 6, 2016): Okey, I solved it, as @cedarlug said it was not a LGSM problem. you can see the last part of the strace here: http://pastebin.com/iCHBKNYY for some reasons, the server try to bind itself on every interface I had on the server, especially sono old virtual interface of lo ``` write(1, "IP address: 127.0.0.1\n", 22) = 22 write(1, "IP address: 127.0.0.4\n", 22) = 22 write(1, "IP address: 127.0.0.5\n", 22) = 22 write(1, "IP address: 127.0.0.6\n", 22) = 22 write(1, "IP address: 127.0.0.7\n", 22) = 22 write(1, "IP address: 127.0.0.8\n", 22) = 22 write(1, "IP address: 127.0.0.9\n", 22) = 22 ``` these interface aren't UP but still resident in interfaces file of debian, I had to comment them out and unfortunately reboot the server (networking restart was not enough) thanks to everyone for the effort!

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jun 6, 2016):

Glad you got it solved !
Have a great time using LGSM :)

@UltimateByte commented on GitHub (Jun 6, 2016): Glad you got it solved ! Have a great time using LGSM :)

kerem commented

2026-02-27 02:03:10 +03:00

Author

Owner

@lock[bot] commented on GitHub (Jul 19, 2018):

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock[bot] commented on GitHub (Jul 19, 2018): This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

kerem referenced this issue

2026-02-27 03:53:30 +03:00

[PR #688] [MERGED] Logfiles cleaning #3158