[GH-ISSUE #345] 7 Days To Die stopping #290

Closed
opened 2026-02-27 02:00:40 +03:00 by kerem · 8 comments
Owner

Originally created by @chriskoepf on GitHub (Apr 19, 2015).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/345

Per conversation in the steam group forums, I'm creating an issue for 7 Days to Die shutdown procedures. The sdtdserver script uses the normal fn_stop function to "kill" any server processes. While this does indeed stop the server, it causes the day and time to be reset. At next server start, it will be Day 1 at 8am. The fix for this is a graceful shutdown using the "shutdown" command via either the built in telnet or web interface.

At present I have added some variables to the main sdtdserver script for telnet settings and then modified the fn_stop function file to check these variables and if the game is 7 Days To Die. If so, it will preform a telnet connection to the server and execute a shutdown command.

I'm not quite sure how to add this code here on git or create a fork.
I did rework my code today so that the fn_stop file should still be universal for all servers used.

Originally created by @chriskoepf on GitHub (Apr 19, 2015). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/345 Per conversation in the steam group forums, I'm creating an issue for 7 Days to Die shutdown procedures. The sdtdserver script uses the normal fn_stop function to "kill" any server processes. While this does indeed stop the server, it causes the day and time to be reset. At next server start, it will be Day 1 at 8am. The fix for this is a graceful shutdown using the "shutdown" command via either the built in telnet or web interface. At present I have added some variables to the main sdtdserver script for telnet settings and then modified the fn_stop function file to check these variables and if the game is 7 Days To Die. If so, it will preform a telnet connection to the server and execute a shutdown command. I'm not quite sure how to add this code here on git or create a fork. I did rework my code today so that the fn_stop file should still be universal for all servers used.
kerem 2026-02-27 02:00:40 +03:00
Author
Owner

@chriskoepf commented on GitHub (Apr 19, 2015):

I created my own fork to the code and submitted my code additions to the sdtdserver script and the fn_stop function file. I don't know if I need to create a pull request or not.

<!-- gh-comment-id:94235104 --> @chriskoepf commented on GitHub (Apr 19, 2015): I created my own fork to the code and submitted my code additions to the sdtdserver script and the fn_stop function file. I don't know if I need to create a pull request or not.
Author
Owner

@dgibbs64 commented on GitHub (Apr 19, 2015):

Just seen the code looks good. I will test this myself and make any modifications. I have just created a development branch for LGSM. If you could do a pull request to the dev branch and I will make any changes then merge to master. Thanks for the code :D

<!-- gh-comment-id:94256652 --> @dgibbs64 commented on GitHub (Apr 19, 2015): Just seen the code looks good. I will test this myself and make any modifications. I have just created a development branch for LGSM. If you could do a pull request to the dev branch and I will make any changes then merge to master. Thanks for the code :D
Author
Owner

@dgibbs64 commented on GitHub (Apr 19, 2015):

Looked at the code. It works well :-) . I will be however be adding some automation to ${telnetip} in that it wont require the user to set this in the sdtdserver script. The script will detect what to use automagicly (Will try localhost first if fails tries other options etc).

The main issue currently is error handling isn't really setup.

For example if you restart the server within 30 seconds of starting, telnet will not connect and gives connection refused. This would mean graceful shutdown failed but even if it did fail it would state it succeeded. This means failure is not logged in the scripts log. There are a few instances where telnet could refuse connection.

It would also be useful for the script to be able to confirm the server shutdown did work e.g capturing telnet output and then picking up a word or phrase like "Disconnect". I have never used expect but I assume there is a way to capture the output from.

'''
spawn telnet 127.0.0.1 8081
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Please enter password:
password
Logon successful.

*** Connected with 7DTD server.
*** Server version: Alpha 11.3 (b8) Compatibility Version: Alpha 11.3
*** Dedicated server only build

Server IP: Any
Server port: 26900
Max players: 8
Game mode: GameModeSurvivalMP
World: Navezgane
Game name: My Game
Difficulty: 2

Press 'help' to get a list of all commands. Press 'exit' to end session.

shutdown
2015-04-19T23:53:06 49.668 INF Executing command 'shutdown' by Telnet from 127.0.0.1:38573
Shutting server down...
2015-04-19T23:53:06 49.758 INF Disconnect
2015-04-19T23:53:06 49.760 INF [NET] DisconnectedFromServer: Server shut down
2015-04-19T23:53:06 49.762 INF SaveAndCleanupWorld
2015-04-19T23:53:06 49.884 INF Saving 0 of chunks took 20ms
2015-04-19T23:53:06 49.889 INF [Steamworks.NET] Stopping server
2015-04-19T23:53:07 50.536 INF World.Unload
2015-04-19T23:53:07 50.539 INF Exited thread thread_GenerateChunks
2015-04-19T23:53:07 50.559 INF Exited thread thread_Pathfinder
2015-04-19T23:53:07 50.566 INF World.Cleanup
2015-04-19T23:53:07 50.570 INF Exited thread thread_Regenerating
2015-04-19T23:53:07 50.766 INF Persistent GamePrefs saved
2015-04-19T23:53:07 50.784 INF Cleanup
Connection closed by foreign host.
'''

<!-- gh-comment-id:94318995 --> @dgibbs64 commented on GitHub (Apr 19, 2015): Looked at the code. It works well :-) . I will be however be adding some automation to ${telnetip} in that it wont require the user to set this in the sdtdserver script. The script will detect what to use automagicly (Will try localhost first if fails tries other options etc). The main issue currently is error handling isn't really setup. For example if you restart the server within 30 seconds of starting, telnet will not connect and gives connection refused. This would mean graceful shutdown failed but even if it did fail it would state it succeeded. This means failure is not logged in the scripts log. There are a few instances where telnet could refuse connection. It would also be useful for the script to be able to confirm the server shutdown did work e.g capturing telnet output and then picking up a word or phrase like "Disconnect". I have never used expect but I assume there is a way to capture the output from. ''' spawn telnet 127.0.0.1 8081 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. Please enter password: password Logon successful. **\* Connected with 7DTD server. **\* Server version: Alpha 11.3 (b8) Compatibility Version: Alpha 11.3 **\* Dedicated server only build Server IP: Any Server port: 26900 Max players: 8 Game mode: GameModeSurvivalMP World: Navezgane Game name: My Game Difficulty: 2 Press 'help' to get a list of all commands. Press 'exit' to end session. shutdown 2015-04-19T23:53:06 49.668 INF Executing command 'shutdown' by Telnet from 127.0.0.1:38573 Shutting server down... 2015-04-19T23:53:06 49.758 INF Disconnect 2015-04-19T23:53:06 49.760 INF [NET] DisconnectedFromServer: Server shut down 2015-04-19T23:53:06 49.762 INF SaveAndCleanupWorld 2015-04-19T23:53:06 49.884 INF Saving 0 of chunks took 20ms 2015-04-19T23:53:06 49.889 INF [Steamworks.NET] Stopping server 2015-04-19T23:53:07 50.536 INF World.Unload 2015-04-19T23:53:07 50.539 INF Exited thread thread_GenerateChunks 2015-04-19T23:53:07 50.559 INF Exited thread thread_Pathfinder 2015-04-19T23:53:07 50.566 INF World.Cleanup 2015-04-19T23:53:07 50.570 INF Exited thread thread_Regenerating 2015-04-19T23:53:07 50.766 INF Persistent GamePrefs saved 2015-04-19T23:53:07 50.784 INF Cleanup Connection closed by foreign host. '''
Author
Owner

@chriskoepf commented on GitHub (Apr 19, 2015):

Good point. I was having some issues with it not connecting. What I had done originally was to create a separate file for just the expect script portion. Then I called the file form within the regular stop function.

So in this:

else
tmux kill-session -t ${servicename}
fn_printok "${servername}"

I put the IF statement where the tmux kill-session line is. If the game is sdtd, it called the expect script for the telnet shutdown, if not, it still ran the tmux line.
I felt it was better to include the expect code in the fn_stop file though, rather than add a new file. When I put the new code together, It didn’t like the IF statement for PID with the print fail and script log. I couldn’t figure it out at all and decided to do it the way it is now.

As far as Expect…. I didn’t know anything about it until 2-3 days ago when I looked up how to connect to telnet from a bash script. There probably is a way to capture the output or even use bash to capture the echo output since everything is being displayed to the screen.

I suppose a check afterward to see if the tmux session still exists would work to see if it shutdown. Put in a pause for a few seconds to allow for the telnet to complete it’s shutdown and then check for the PID.

Like I said, I just figure out the Expect code a couple days ago and last night rewrote it all to put it into the fn_stop file instead of having a separate file. But, the separate file seemed to work better I guess.

I don’t know what to do about stopping right after starting again. My server did seem to respond pretty quick. Maybe a PID check to verify it’s running, then telnet. If telnet fails, wait 10 seconds and try again? I don’t know.

<!-- gh-comment-id:94322403 --> @chriskoepf commented on GitHub (Apr 19, 2015): Good point. I was having some issues with it not connecting. What I had done originally was to create a separate file for just the expect script portion. Then I called the file form within the regular stop function. So in this: else tmux kill-session -t ${servicename} fn_printok "${servername}" I put the IF statement where the tmux kill-session line is. If the game is sdtd, it called the expect script for the telnet shutdown, if not, it still ran the tmux line. I felt it was better to include the expect code in the fn_stop file though, rather than add a new file. When I put the new code together, It didn’t like the IF statement for PID with the print fail and script log. I couldn’t figure it out at all and decided to do it the way it is now. As far as Expect…. I didn’t know anything about it until 2-3 days ago when I looked up how to connect to telnet from a bash script. There probably is a way to capture the output or even use bash to capture the echo output since everything is being displayed to the screen. I suppose a check afterward to see if the tmux session still exists would work to see if it shutdown. Put in a pause for a few seconds to allow for the telnet to complete it’s shutdown and then check for the PID. Like I said, I just figure out the Expect code a couple days ago and last night rewrote it all to put it into the fn_stop file instead of having a separate file. But, the separate file seemed to work better I guess. I don’t know what to do about stopping right after starting again. My server did seem to respond pretty quick. Maybe a PID check to verify it’s running, then telnet. If telnet fails, wait 10 seconds and try again? I don’t know.
Author
Owner

@dgibbs64 commented on GitHub (Apr 20, 2015):

I have made a few changes myself
https://github.com/dgibbs64/linuxgsm/blob/development/functions/fn_stop

Keep uploading your changes to your repo and I can see what you are up to and I can comment and make my own changes :)

If fails waiting x seconds would be a good idea.

<!-- gh-comment-id:94397443 --> @dgibbs64 commented on GitHub (Apr 20, 2015): I have made a few changes myself https://github.com/dgibbs64/linuxgsm/blob/development/functions/fn_stop Keep uploading your changes to your repo and I can see what you are up to and I can comment and make my own changes :) If fails waiting x seconds would be a good idea.
Author
Owner

@dgibbs64 commented on GitHub (May 3, 2015):

I have now implemented this feature

<!-- gh-comment-id:98475474 --> @dgibbs64 commented on GitHub (May 3, 2015): I have now implemented this feature
Author
Owner

@zian92 commented on GitHub (Nov 9, 2017):

aswesome explanation why I observed telnet errors (disabled in the server settings)

[ERROR ] Stopping sdtdserver: Graceful: telnet: 127.0.0.1: FAIL
[ERROR ] Stopping sdtdserver: Graceful: telnet: 188.68.51.84: FAIL
[ERROR ] Stopping sdtdserver: Graceful: telnet: FAIL
<!-- gh-comment-id:343163970 --> @zian92 commented on GitHub (Nov 9, 2017): aswesome explanation why I observed telnet errors (disabled in the server settings) ``` [ERROR ] Stopping sdtdserver: Graceful: telnet: 127.0.0.1: FAIL [ERROR ] Stopping sdtdserver: Graceful: telnet: 188.68.51.84: FAIL [ERROR ] Stopping sdtdserver: Graceful: telnet: FAIL ```
Author
Owner

@lock[bot] commented on GitHub (Nov 9, 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.

<!-- gh-comment-id:437393047 --> @lock[bot] commented on GitHub (Nov 9, 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.
Sign in to join this conversation.
No labels
Atomic
Epic
cannot reproduce
command: backup
command: console
command: debug
command: details
command: fast-dl
command: install
command: mods
command: monitor
command: post-details
command: restart
command: send
command: start
command: stop
command: update
command: update-lgsm
command: validate
command: wipe
distro: AlmaLinux
distro: Arch Linux
distro: CentOS
distro: Debian
distro: Fedora
distro: RedHat
distro: Rocky Linux
distro: Ubuntu
distro: openSUSE
engine: goldsrc
engine: source
game: 7 Days to Die
game: ARMA 3
game: Ark: Survival Evolved
game: Assetto Corsa
game: Avorion
game: BATTALION: Legacy
game: Barotrauma
game: Battalion 1944
game: Battlefield 1942
game: Black Mesa: Deathmatch
game: Blade Symphony
game: Call of Duty 2
game: Call of Duty 4
game: Call of Duty: United Offensive
game: Counter-Strike 1.6
game: Counter-Strike 2
game: Counter-Strike: Global Offensive
game: Counter-Strike: Source
game: Day of Infamy
game: Dayz
game: Death Match Classic
game: Don't Starve Together
game: ET: Legacy
game: Eco
game: Factorio
game: Factorio
game: Garry's Mod
game: Half-Life
game: Hurtword
game: Insurgecy
game: Insurgecy
game: Insurgency: Sandstorm
game: Just Cause 3
game: Killing Floor
game: Killing Floor 2
game: Left 4 Dead 2
game: Minecraft
game: Minecraft Bedrock
game: Mordhau
game: Multi Theft Auto
game: Mumble
game: Natural Selection 2
game: No More Room in Hell
game: Pavlov VR
game: Post Scriptum
game: Project Zomboid
game: Quake 3
game: QuakeWorld
game: Red Orchestra: Ostfront 41-45
game: Return to Castle Wolfenstein
game: Rising World
game: Rust
game: San Andreas Multiplayer
game: Satisfactory
game: Soldat
game: Soldier of Fortune 2
game: Squad
game: Squad 44
game: Starbound
game: Stationeers
game: Sven Co-op
game: Team Fortress 2
game: Teamspeak 3
game: Teeworlds
game: Terraria
game: The Front
game: Unreal Tournament 2004
game: Unreal Tournament 3
game: Unreal Tournament 99
game: Unturned
game: Valheim
game: Wurm Unlimited
game: Zombie Master Reborn
game: label missing
good first issue
help wanted
info: alerts
info: dependency
info: docker
info: docs
info: email
info: query
info: steamcmd
info: systemd
info: tmux
info: website
info: website
needs more info
outcome: duplicate
outcome: issue resolved
outcome: issue resolved
outcome: issue unresolved
outcome: pr accepted
outcome: pr rejected
outcome: unconfirmed
outcome: wontfix
outcome: wrong forum
potential-duplicate
priority
pull-request
type: bug
type: feature
type: feature
type: feature request
type: game server request
type: refactor
waiting response
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/LinuxGSM#290
No description provided.