Dedicated servers/Running as a Service

From Satisfactory Wiki
Jump to navigation Jump to search

This page describes how to set up the Satisfactory dedicated server as a service.

Running as a Service

Running the dedicated server as a service allows the game server to automatically restart in the event of a crash, as well as to automatically start after system boot. How this is handled depends on the operating system used.

Linux

Systemd

Systemd is the default service management system for many Linux distributions.

The following is an example systemd unit file for the Satisfactory service. It uses SteamCMD to check for updates any time the server is started or restarted. It will also start the server after the host is booted.

Edit the user and path to reflect the location and owner of the Satisfactory installation. The unit file should be placed at /etc/systemd/system/satisfactory.service

[Unit]
Description=Satisfactory dedicated server
Wants=network-online.target
After=syslog.target network.target nss-lookup.target network-online.target

[Service]
ExecStartPre=/usr/games/steamcmd +force_install_dir "/home/your_user/SatisfactoryDedicatedServer" +login anonymous +app_update 1690800 validate +quit
ExecStart=/home/your_user/SatisfactoryDedicatedServer/FactoryServer.sh
User=your_user
Group=your_user
Restart=on-failure
RestartSec=60
KillSignal=SIGINT
WorkingDirectory=/home/your_user/SatisfactoryDedicatedServer

[Install]
WantedBy=multi-user.target

Besides logging to the journal (by default), the server also writes its logs to <satisfactory_install_dir>/FactoryGame/Saved/Logs. Log files are rotated automatically when the server process is restarted. See Dedicated_servers#Logs_and_crash_dumps for more.

Note that KillSignal=SIGINT should be set in the Service block of the service file, and SIGTERM is the default if not set.[1] Sending SIGTERM to the process kills the process immediately and does not process or log any exit behavior. The server process does not automatically save the game even on graceful shutdown, so when stopping the service, ensure that players are not connected, or if they are, manually run a save command before stopping. Enabling the "Auto-Save on Player Disconnect" server option is recommended.

After creating the service, systemd will need to be reloaded to load the new service:

$ sudo systemctl daemon-reload

To enable and start the service, use the following two commands respectively:

$ sudo systemctl enable satisfactory
$ sudo systemctl start satisfactory

Service status can be checked with sudo systemctl status satisfactory. If configured correctly, the output should look like:

* satisfactory.service - Satisfactory dedicated server
     Loaded: loaded (/etc/systemd/system/satisfactory.service; linked; preset: enabled)
     Active: active (running) since Wed 2024-09-11 23:01:03 UTC; 1s ago
   Main PID: 7813 (FactoryServer.s)
      Tasks: 21 (limit: 18998)
     Memory: 151.3M
        CPU: 1.632s
     CGroup: /system.slice/satisfactory.service
             |-7813 /bin/sh /home/steam/Steam/SatisfactoryDedicatedServer/FactoryServer.sh
             `-7820 /home/steam/Steam/SatisfactoryDedicatedServer/Engine/Binaries/Linux/FactoryServer-Linux-Shipping FactoryGame

If the service times out before it is loaded, it may restart in a loop. This may happpen if older hardware that doesn't meet the minimum requirements for the server hardware is being used. To prevent this, the following line can be added to the [Service] section:TimeoutSec=XXX. Replace the XXX with a numerical value in seconds. On most distros services timeout after 90 seconds by default.

NixOS (and other Atomic distros) Systemd Quirks

If you are creating a Service using steam-run on NixOS with Systemd, ensure you are calling for the steam-run binary via the source binary, with ${pkgs.steam-run}/bin/steam-run. Attempting to use the binary atomically linked inside /run/current-system/sw/bin/steam-run will make the service not start correctly. For an example of the design of the Service unit inside Nix, see this: Satisfactory Service Nix. See Systemd bug reported here for more information: Systemd issue 31941 for further information and monitoring progress.

Experimental Branch

To have systemd pre-fetch the Experimental branch of the Dedicated Server upon restart, adjust the ExecStartPre directive to tell SteamCMD to use the experimental branch, as follows (truncated for brevity):

[Service]
#...
ExecStartPre=/usr/games/steamcmd +force_install_dir "/home/your_user/SatisfactoryDedicatedServer" +login anonymous +app_update 1690800 -beta experimental validate +quit
#...
Planned graceful Restart

Together with the HTTPS API the Service can be configured to save, update and restart automaticaly. Here is an example using a cron job and curl.

##Example cron tab config
# m h  dom mon dow   command
00 <RESTART_TIME>  * * * /usr/bin/curl -s --location 'https://<IP_ADDRESS>:7777/api/v1' --insecure --header 'Content-Type: application/json' --data '{"function" :"PasswordLogin","data": {"Password": "<PASSWORD>","MinimumPrivilegeLevel": "Administrator"}}' | /usr/bin/jq -r '.data.authenticationToken' | xargs -I{} /usr/bin/curl -s --location 'https://<IP_ADDRESS>:<PORT>/api/v1' --insecure --header 'Content-Type: application/json' --header "Authorization: Bearer {}" --data '{"function" :"SaveGame","data": {"SaveName": "main"}}' && sleep 15 && /usr/sbin/service satisfactory restart

##Restart Command Step-by-Step (without absolut paths)
#Get authenticationToken
token=$(curl -s --location 'https://<IP_ADDRESS>:7777/api/v1' --insecure --header 'Content-Type: application/json' --data
'{
"function" :"PasswordLogin"
"data": {"Password": "<PASSWORD>","MinimumPrivilegeLevel": "Administrator"}
}'
| jq -r '.data.authenticationToken')
#Save Game 
&&
curl -s --location 'https://<IP_ADDRESS>:7777/api/v1' --insecure --header 'Content-Type: application/json' --header "Authorization: Bearer ${token}" --data
'{
"function" :"SaveGame",
"data": {"SaveName": "<SAVE_GAME_NAME>"}
}'
#Wait 15 seconds (unknow if SaveGame function is synchronous)
&&
sleep 15
#Restart Service (also updates the server)
&&
service satisfactory restart

OpenRC

OpenRC is a service management system for Gentoo Linux.

Install SteamCMD using Portage, and accept its license. Its installation directory by default is /opt/steamcmd.

The recommended way to get it set up is to link to the already existing SteamCMD init file with ln -s /etc/init.d/steamcmd /etc/init.d/steamcmd.satisfactory and then copying the default config from /etc/conf.d/steamcmd to /etc/conf.d/steamcmd.satisfactory.

The completed /etc/conf.d/steamcmd.satisfactory would look something like this:

# Copyright 1999-2020 Gentoo Authors 
# Distributed under the terms of the GNU General Public License v2 

# Dtach options, which will used, when the `attach` extra command is called. 
# By default, CTRL+D is used, and no signal is send, 
# when you want to detach from the attached console. 
DTACH_OPTS="-e '^D' -r none" 
# Specifies, which server binary is used. 
# This could be 'hlds_run' or 'srcds_run', depending on your game. 
STEAMCMD_BINARY="FactoryServer.sh" 
# Path to the files of your started server. 
STEAMCMD_PATH="/opt/steamcmd/sf" 
# Options for your server binary. 
STEAMCMD_OPTS=""

Windows

NSSM

You can use Non-Sucking Service Manager to easily set up auto-restart for the dedicated server.

Once you've downloaded and installed NSSM, navigate to the directory containing nssm.exe and run the below command:

nssm.exe install SatisfactoryServerService

This will pull up a GUI for configuration. Set the "Path" to the location of FactoryServer.exe, Set the "Arguments" to "-unattended". You can modify other settings if you want, but that's the only required step. Click "install", then run this command.

nssm.exe start SatisfactoryServerService

Other useful nssm commands:

nssm.exe status SatisfactoryServerService # Checks the status of the Service
nssm.exe stop SatisfactoryServerService # Stops the service, and prevents it from auto-restarting

NSSM to update your server

First create a batch file with the following text and save it as Update.bat in the same directory as Factory.exe. Remember to put the directory on your server for where the Steamcmd.exe and Factory.exe files are. For this example they reside in the C:\Gameservers directory.

"C:\GameServers\SteamCMD\steamcmd.exe" +force_install_dir "C:\GameServers\SatisfactoryServer" +login anonymous +app_update 1690800 -beta public validate +quit
"C:\GameServers\nssm.exe" start SatisfactoryServerService
"C:\GameServers\nssm.exe" stop SatisfactoryServerUpdate

Next open up your command prompt and change directories to where nssm.exe and run the command below:

nssm.exe install SatisfactoryServerUpdate

Set the "Path" to the location of Update.bat. Set the startup type to Automatic. Under the Exit Actions tab and restart area select: Stop service (oneshot mode). Click "install" Run the command below:

nssm.exe edit SatisfactoryServerService

Under the Details tab change the Startup type to "Manual" then Click "Edit service." Now run the following command:

nssm.exe start SatisfactoryServerUpdate

This will have steamcmd look for any update, download, install, and verify it. Then it will quit and start your Satisfactory server. This will also stop the update service.

Automating Server Updates With Task Scheduler

You can further automate this function by using the Windows Task Scheduler.

Run the task scheduler and open up the library. Right click in the big window and click "Create New Task..." In the General tab under account ensure you put an administrative service account to run the task. On the triggers tab you can set an option to have it run. If you would like to have the server check every day 2am you can set a new trigger. Have the task begin on a schedule. Run it daily at 2:00am. Set the task to enabled and click "Ok." Go to the Actions tab. You're going to want to start the next two programs:

NET STOP "SatisfactoryServerService"
NET START "SatisfactoryServerUpdate"

Click "OK" to save. Now your server will automatically shutdown at 2am, search for an update, install it if found, and restart without any human interaction. You can check to see if this is running in the task scheduler window or within the event viewer under the application tab.

Docker


See also