Game server events

Game servers meet many events throughout their lifecycles. This section covers unusual and unexpected events, such as misbehavior and crashes. For other events, refer to the server lifecycle.

Misbehavior

When a game server misbehaves, it means something unexpected (other than a crash) happened with the build executable process. Usually, this means the build executable process started using more resources (CPU and memory) than the server slot allows or stopped responding to queries for an extended period of time.

Game Server Hosting checks for misbehaving servers using a series of game server checks that run every minute. These checks ensure that the build executable process is:

  1. Within the expected CPU usage limits (with a 10% tolerance).
  2. Within the expected memory usage limits (with a 200 megabyte tolerance).
  3. Responding to queries.✝

Note: Game Server Hosting only checks if game servers respond to queries if you implement a query protocol in the build and specify it in the build configuration.

If Game Server Hosting detects that a build executable process is misbehaving, it sends the process a SIGSEGV signal. By default, Game Server Hosting only considers build executables as misbehaving if they fail the same check three times within a 30-minute period.

Server check cycle - CPU failure

Crashes

A crash refers to an unintentional termination of a build executable process with any exit code other than 0 (opposed to an intentional exit). The recommended best practice is to have a build executable exit with a non-zero exit code when it meets an issue from which is can't recover.

When Game Server Hosting detects that a build executable crashed, it attempts to recover the game session by restarting it with the same allocation ID. However, if the build executable continues to crash, Game Server Hosting backs off and stops trying to recover the game session.

Allocation pre-recovery

The allocation pre-recovery process prevents Game Server Hosting from automatically restarting game servers that were allocated when they crashed.

Note: Game Server Hosting only detects crashes if you implement a query protocol in the build and specify it in the build configuration.

When Game Server Hosting detects that a game server no longer responds to server state queries (using the implemented server query protocol), it checks if the game server was allocated during the crash by reading the allocation UUID.

If the game server doesn’t have an allocation UUID, Game Server Hosting restarts the build executable process. If the game server continues to crash, Game Server Hosting stops restarting the game server. Refer to crash backoff.

If the game server has an allocation UUID, Game Server Hosting won’t restart the game server process. Instead, the game server remains stopped until it receives a new allocation. This prevents Game Server Hosting from starting game servers with stale allocation information.

Crash back-off

Game Server Hosting backs off and stops trying to recover a game session by restarting the build executable if the build executable process crashes more than a specific number✝ of times within a 30-minute period.

Note: By default, Game Server Hosting only tries to restart the build executable process once (if the servers are running on a cloud machine).

Unity logo Documentation
Copyright © 2024 Unity Technologies
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.