Server Management

Server Management

This page covers install, start, stop, restart, update, console interaction, automation, and Minecraft-specific management details.

Home

10. Server Management

10.1 Creating and Installing Servers

Server Manager supports three types of server installations:

Steam Dedicated Servers: Installation is performed through SteamCMD, Valve's command-line tool for downloading and updating Steam game servers. The process:

1. The user provides the Steam App ID, server name, and installation directory.
2. Server Manager invokes SteamCMD with the appropriate parameters: steamcmd +login <username> +force_install_dir <dir> +app_update <appid> validate +quit.
3. SteamCMD handles downloading the server files. Server Manager monitors the process and handles 40+ error codes.
4. Login can be anonymous (for free dedicated servers) or authenticated (for servers requiring a Steam account). Steam Guard TOTP codes are supported.
5. After installation, the server configuration is saved to the database with all metadata.

Minecraft Servers: Minecraft server installation supports four modloaders:

1. Vanilla — Downloads the official server JAR from Mojang's version manifest.
2. Fabric — Downloads from the Fabric meta API.
3. Forge — Downloads from the Forge promotions/downloads CDN.
4. NeoForge — Downloads from the NeoForge API.

The installer also handles EULA auto-acceptance, launch script creation (with appropriate Java arguments), and server detection.

Custom Servers: You can add any executable as a managed server by providing the executable path and working directory.

10.2 Starting Servers

Starting a server (ServerManager.start_server_advanced()) involves:

1. Corruption Detection — Checks the installation directory for signs of corrupted or incomplete installations.
2. Executable Resolution — Handles multiple executable types: batch scripts (.bat, .cmd), executables (.exe), and Java JARs (.jar). For batch scripts, the command is wrapped with cmd.exe /c. For JAR files, the Java executable is used.
3. Process Creation — The server process is started with subprocess.Popen. Console window visibility is controlled by the hideServerConsoles configuration option. Stdin, stdout, and stderr are captured for console interaction.
4. Retry Logic — If the first start attempt fails, up to 3 retries are attempted with different strategies (e.g., adjusting working directory, retrying with different executable detection).
5. Process Registration — The PID, process creation time, and status are recorded in the database.
6. Stdin Relay Setup — The command input infrastructure (named pipes, command queue) is initialised for the new server process.
7. Post-Start Commands — If a start command is configured in the automation settings, it is executed on the server after a brief startup delay.

10.3 Stopping Servers

Stopping a server (ServerManager.stop_server_advanced()) uses a multi-strategy graceful shutdown approach:

1. Stop Command via Stdin — If a stop command is configured (e.g., stop, exit, quit), it is sent to the server via the stdin relay infrastructure.
2. SIGTERM — A terminate signal is sent to the process.
3. Window Close — On Windows, attempts to close the process's main window.
4. Ctrl+C Event — Sends a CTRL_C_EVENT to the process group.
5. Force Kill — If none of the graceful methods succeed within the timeout period, the process is forcefully terminated using taskkill /F /T (with child processes).

After the process exits, the PID and status are updated in the database, and stdin relay resources are cleaned up.

10.4 Restarting Servers

Restarting a server (ServerManager.restart_server_advanced()) combines the stop and start sequences:

1. Initiate stop with the graceful shutdown sequence.
2. Wait for the process to fully exit.
3. Initiate start with the standard startup sequence.
4. A callback function can be provided for progress reporting.

If pre-restart warnings are configured, the restart operation first sends countdown warnings at the configured intervals before initiating the stop.

10.5 Server Updates

The update system (Modules/updates/server_updates.py, ServerUpdateManager) provides both on-demand and scheduled update checking:

Manual Update Check: For Steam servers, the update checker queries SteamCMD's app_info_print command with a 2-minute timeout to compare the installed build ID against the latest available build ID. If a newer version is available, the server can be updated.

Automatic Update Process:

1. Stop the server (if running).
2. Run SteamCMD to update the server files (+app_update <appid> validate).
3. Restart the server.
4. The in_progress flag prevents concurrent update operations on the same server.

Scheduled Updates:

• Global Schedule — A global update schedule can be configured to check all servers at a specific time window. The system supports daily and weekly schedules with a 30-minute time window for flexibility.
• Per-Server Schedule — Individual servers can have their own update schedules that override the global schedule.
• Scattered Restarts — To avoid restarting all servers simultaneously, a hash of the server name is used to compute a consistent time offset, scattering restarts across the schedule window.

Pre-Restart Warnings: Before restarting a server for updates, warning messages are broadcast to connected players at configurable intervals. The default intervals are 30, 15, 10, 5, and 1 minutes before the restart. The warning message template supports a {message} placeholder that is replaced with the remaining time. Warning delivery uses the shared send_command_to_server() utility from common.py, which tries the persistent stdin pipe first and falls back to the file-based command queue.

Batch Updates: The update_all_steam_servers() method checks and updates all Steam servers sequentially with a 2-second delay between servers to avoid overwhelming the system or SteamCMD.

10.6 Server Console and Command Input

See Section 7.4: Server Console for the full description of the console system and its five command delivery methods.

10.7 Server Automation (MOTD, Warnings, Schedules)

The Server Automation system (Modules/services/server_automation.py, ServerAutomationManager) runs as a background process and handles:

MOTD Broadcasting:

• A background thread checks all server configurations every 60 seconds.
• For each server with MOTD enabled (interval > 0 and message non-empty), it checks if enough time has elapsed since the last broadcast.
• If the server is running and it is time, the MOTD command is sent to the server with {message} replaced by the configured message text.
• Broadcast timestamps are tracked per-server to maintain accurate intervals.

Restart Warnings:

• When a scheduled restart is approaching, warning messages are sent at the configured intervals (e.g., "Server restarting in 30 minutes", "Server restarting in 15 minutes", etc.).
• The warning command and message template are per-server settings.
• Warning delivery uses the shared send_command_to_server() utility from common.py.

Start Commands:

• After a server starts, configured start commands are automatically executed.
• This is useful for servers that need initialisation commands after boot.

---

11. Minecraft Server Management

11.1 Supported Modloaders

Server Manager supports four Minecraft modloaders:

1. Vanilla — The official Mojang server JAR. Downloaded directly from Mojang's version manifest API (https://launchermeta.mojang.com/mc/game/version_manifest_v2.json). Supports all release and snapshot versions.

2. Fabric — A lightweight, modular modloader. Downloaded from the Fabric meta API (https://meta.fabricmc.net/). Popular for performance-focused mod packs.

3. Forge — The most established modloader for Minecraft. Downloaded from the Forge promotions API (https://files.minecraftforge.net/). Supports a vast ecosystem of mods.

4. NeoForge — A community fork of Forge with modern API improvements. Downloaded from the NeoForge API (https://maven.neoforged.net/).

11.2 Java Version Management

Different Minecraft versions require different Java versions. Server Manager includes automatic Java detection and version matching:

Minecraft Version	Required Java Version
1.16 and earlier	Java 8
1.17	Java 16
1.18 – 1.20	Java 17
1.21 and later	Java 21

Java Detection: The detect_java_installations() function scans common Windows installation paths:

• JAVA_HOME environment variable
• C:\Program Files\Java\*
• C:\Program Files (x86)\Java\*
• C:\Program Files\Eclipse Adoptium\*
• C:\Program Files\Amazon Corretto\*
• C:\Program Files\Microsoft\*
• System PATH directories

For each detected installation, the function extracts the version string and validates the Java binary.

Compatibility Checking: check_java_compatibility() compares a detected Java installation against the requirements for a specific Minecraft version and reports whether it is compatible, along with recommendations if not.

11.3 Java Configurator CLI

The Java Configurator (Modules/updates/java_configurator.py) is a command-line tool for managing Java installations:

# List all detected Java installations
python Modules/updates/java_configurator.py list-java

# List all Minecraft servers from the database
python Modules/updates/java_configurator.py list-servers

# Check Java compatibility for a server
python Modules/updates/java_configurator.py check --server "My Minecraft Server"

# Configure Java for a server (auto-selects if not specified)
python Modules/updates/java_configurator.py configure --server "My Minecraft Server" --java "C:\Program Files\Java\jdk-21\bin\java.exe"

---