Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dedicated server slow to stop while generating map #8878

Closed
Berbe opened this issue Mar 20, 2021 · 6 comments · Fixed by #9013
Closed

Dedicated server slow to stop while generating map #8878

Berbe opened this issue Mar 20, 2021 · 6 comments · Fixed by #9013
Labels
needs triage This issue needs further investigation before it becomes actionable

Comments

@Berbe
Copy link
Contributor

Berbe commented Mar 20, 2021

Version of OpenTTD

1.11.0-RC1

Expected result

Server stops quickly (within a few seconds)

Actual result

Server takes too long to stop.
Timed at ~1m on a 2,048 x 2,048 map (map_x = map_y = 11).

[2021-03-20 17:15:53] dbg: [net] Map generation percentage complete: 5
^C[2021-03-20 17:15:55] dbg: [net] Generating map failed, aborting
[2021-03-20 17:16:12] dbg: [net] [udp] received new session key from master server (IPv4)
[2021-03-20 17:16:12] ‎*** Game paused (number of players)
[2021-03-20 17:16:12] dbg: [net] [udp] advertising to master server
[2021-03-20 17:16:12] dbg: [misc] Renaming /home/openttd/.openttd/openttd.cfg.new to /home/openttd/.openttd/openttd.cfg failed; configuration not saved
[2021-03-20 17:16:12] dbg: [net] [udp] removing advertise from master server
[2021-03-20 17:16:52] dbg: [net] [server] closed listeners
[2021-03-20 17:16:52] dbg: [net] [admin] closed listeners
[2021-03-20 17:16:52] dbg: [net] [udp] closed listeners
[2021-03-20 17:16:52] dbg: [net] [udp] initializing listeners
[2021-03-20 17:16:52] dbg: [net] [udp] closed listeners
[2021-03-20 17:16:52] dbg: [net] [core] shutting down network

Note: server_advertise = true
The rest of openttd.cfg does not seem to matter.

Steps to reproduce

openttd -D
<Ctrl-C (SIGINT)>

Also reproducible by sending SIGTERM
@James103
Copy link
Contributor

James103 commented Mar 20, 2021 •
edited

How long does it take for the server to generate a 2048 x 2048 map without you interrupting the process? If that's close to the 1 minute mentioned, then there's a possibility that the server is finishing generating the map before exiting, even if it received a force-exit (SIGINT or SIGTERM) signal.

Also, I can't seem to reproduce this on Windows 10. What OS and CPU are you running this on?

@Berbe
Copy link
Contributor Author

Berbe commented Mar 20, 2021 •
edited

there's a possibility that the server is finishing generating the map before exiting, even if it received a force-exit (SIGINT or SIGTERM) signal.

I concur on that hunch.
However, it does not solely explain the whole thing, notably the time after messages related to the advertisement to the master server.

Also, I can't seem to reproduce this on Windows 10. What OS and CPU are you running this on?

GNU/Linux (Debian-compatible)
Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz

@Berbe Berbe changed the title Dedicated server slow to stop while generating map Dedicated server slow to stop while generating map when server advertisement is activated Mar 20, 2021
@Berbe Berbe changed the title Dedicated server slow to stop while generating map when server advertisement is activated Dedicated server slow to stop while generating map Mar 20, 2021
@Berbe
Copy link
Contributor Author

Berbe commented Mar 20, 2021 •
edited

OK I am noticing 2 distinct problems:

  1. Map generation seems to continue even if an interrupt signal is received
  2. Server stop is delayed for exactly 40 more seconds when server_advertise = true is set in the configuration file. @James103 Was that directive set in your test setup?
    Maybe those 40s are required to acknowledge answers from the master server? Anyhow, it seems way too long, as it slows the stopping sequence more than it is reasonably expected.

@James103
Copy link
Contributor

James103 commented Mar 20, 2021 •
edited

@James103 Was that directive set in your test setup?

I can reproduce the server stop delay if I run the exit console command from the server, but not if I hit control-C or press the close button to stop the server. Again, I'm running this on Windows 10.

@Berbe Are you port-forwarding the specific port your server is listening to through your router? If not, the advertise to master server will fail early and will not cause the server stop to be delayed.

@Berbe
Copy link
Contributor Author

Berbe commented Mar 25, 2021 •
edited

The advertisement does not fail if I let the startup sequence finish. It works flawlessly in both IPv4 & IPv6

@TrueBrain TrueBrain added the needs triage This issue needs further investigation before it becomes actionable label Apr 10, 2021
@Berbe Berbe mentioned this issue Apr 11, 2021
Closed
@Berbe
Copy link
Contributor Author

Berbe commented Apr 11, 2021

As noted in #9001, in case of a slow communication between the game and master server (for instance, resulting from delayed DNS traffic), acknowledgement of the signal is only done after datagrams have been sent to the master server.
At the same time, communication on the game port is impacted (blocked), which is the purpose of #9001, I reckon.

I trust the best behaviour would be to acknowledge the signal without depending on anything that could block.
Whether to wait on the master server response is a matter of decision: at some point, wouldn't it be better to give up on it to continue shutting the server off without risking to hang eternally?

@LordAro LordAro mentioned this issue Apr 11, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
needs triage This issue needs further investigation before it becomes actionable
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix: getaddrinfo/UDP blocking locks up whole game rubidium42/OpenTTD
3 participants
@TrueBrain @Berbe @James103