starred/LinuxGSM

Fork 0

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

[GH-ISSUE #1745] 7 Days to Die - Linux 32-bit vs. 64-bit server startup #1360

New issue

Closed

opened 2026-02-27 02:56:41 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 02:56:41 +03:00

Owner

Originally created by @ThorTheNinja on GitHub (Dec 22, 2017).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1745

Believe this issue may be related to issue #1532. Basically, it seems the server is starting up using the 32-bit version, even if I've changed the startserver.sh to ONLY load the 64 bit version.

if [ "$(uname -m)" = "x86_64" ]; then
      ./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS 
else
      ./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS

When I execute

uname -m

, it does indeed return:
x86_64

How can I force LGSM to run the 64-bit version?

Originally created by @ThorTheNinja on GitHub (Dec 22, 2017). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1745 Believe this issue _may_ be related to issue #1532. Basically, it seems the server is starting up using the 32-bit version, even if I've changed the startserver.sh to ONLY load the 64 bit version. ``` if [ "$(uname -m)" = "x86_64" ]; then ./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS else ./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS ``` When I execute > uname -m , it does indeed return: `x86_64` How can I force LGSM to run the 64-bit version?

kerem

2026-02-27 02:56:41 +03:00

closed this issue
added the
game: 7 Days to Die
label

kerem commented

2026-02-27 02:56:42 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Dec 29, 2017):

Try == instead. There are plans to review handling of x64 bit binary's

if [ "$(uname -m)" == "x86_64" ]; then

@dgibbs64 commented on GitHub (Dec 29, 2017): Try `==` instead. There are plans to review handling of x64 bit binary's ``` if [ "$(uname -m)" == "x86_64" ]; then ```

kerem commented

2026-02-27 02:56:42 +03:00

Author

Owner

@ThorTheNinja commented on GitHub (Jan 4, 2018):

Is there a Linux command to verify whether the current running processes are running as 32 or 64 bit? It would appear to me that the 32-bit version is still getting called.

@ThorTheNinja commented on GitHub (Jan 4, 2018): Is there a Linux command to verify whether the current running processes are running as 32 or 64 bit? It would appear to me that the 32-bit version is still getting called.

kerem commented

2026-02-27 02:56:42 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Jul 21, 2018):

#1436

@dgibbs64 commented on GitHub (Jul 21, 2018): #1436

kerem commented

2026-02-27 02:56:42 +03:00

Author

Owner

@Narquadah commented on GitHub (Nov 23, 2018):

As of Alpha 17 (experimental) I couldn't get the 32-bit to run. The 64 works fine though. To get it to work with LinuxGSM I added executable="./7DaysToDieServer.x86_64" to sdtdserver.cfg.

@Narquadah commented on GitHub (Nov 23, 2018): As of Alpha 17 (experimental) I couldn't get the 32-bit to run. The 64 works fine though. To get it to work with LinuxGSM I added `executable="./7DaysToDieServer.x86_64"` to `sdtdserver.cfg`.

kerem commented

2026-02-27 02:56:42 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Nov 23, 2018):

7 Days to Die will be getting a bit of an overhaul with the recent changes

@dgibbs64 commented on GitHub (Nov 23, 2018): 7 Days to Die will be getting a bit of an overhaul with the recent changes

kerem commented

2026-02-27 02:56:42 +03:00

Author

Owner

@lock[bot] commented on GitHub (Dec 16, 2019):

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 (Dec 16, 2019): 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.