7 Days To Die stopping

[chriskoepf]

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.

[chriskoepf]

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.

[dgibbs64]

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

[dgibbs64]

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.
'''

[chriskoepf]

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.

[dgibbs64]

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.

[dgibbs64]

I have now implemented this feature

[zian92]

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

[lock]

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.