Actium

The dedicated server (DCS_server.exe) cannot be used reliably as a non-interactive background service. For example, failure to login with the sometimes unreliable master server will raise this Login failed popup (if a saved authentication is available): The popup must be closed manually. Afterwards, the server process initializes and the splash screen window opens, but the server refuses to start any mission via the WebGUI and appears to be bricked indefinitely with the following dcs.log error message: 2025-03-03 21:20:24.025 ERROR ASYNCNET (Main): server_start failed: login is required If no saved authentication is available, another popup is opened that must also be acknowledged manually, before the server process terminates (at least the process isn't bricked, this time): UPDATE: An already running dedicated server will terminate with the following Login session has expired popup if the master server is unreachable for more than 20 minutes. The error occurs only when connection to the master server is re-established (more details here). The dedicated server process terminates after acknowledging the popup: Last but not least, a mission scripting error will raise another popup that freezes an already started dedicated server mid-mission until the popup is manually acknowledged (workaround available) : When using DCS_server.exe interactively, i.e., starting a single server instance on your local Desktop only if and when you need it, these popup messages may provide useful debugging information. However, many DCS_server.exe instances run non-interactively on dedicated servers in data centers without constant supervision of the server GUI. If such a popup message opens, e.g., after an automatic restart that leads to a temporary login failure or when a mission scripting error occurs, the server instance is bricked until manual admin intervention. This is highly impractical. DCS_server.exe should support non-interactive use by exiting with a non-zero exit status code immediately after fatal errors, e.g., the login failure*. Non-fatal errors should be logged to dcs.log, but otherwise ignored (or better yet: communicated to the clients as done in my workaround). The operating system service manager or a restart script can then decide if and when to attempt restarting DCS_server.exe after an error occurred, based on the exit status code. To not affect the aforementioned interactive desktop use of DCS_server.exe, a --quiet argument could be introduced, just like DCS_updater.exe has it already. Such an option should inhibit all popups including crash popup and therefore imply crash_report_mode = "silent", so DCS_server.exe can also be restarted automatically after it crashed. *) Regarding the login failure, a superior solution to just exiting would be to repeatedly attempt to connect to the master server in the background. Meanwhile, the server should still be allowed to start a mission, so dedicated servers can still be started and used (by connecting via IP) even if the master server is temporarily unavailable.

Cannot reproduce it either. For me, also behaves like Flappie described. Probably need to contact your managed server provider about it.

Tried with a locally hosted dedicated server (Windows 10, Ryzen 9 5900X, 64G DDR4@3600, and Samsung 990 Pro). Switching between missions on Caucasus takes 2~3 seconds. Switching between Marianas and Caucasus takes roughly 5~7 seconds. I believe, you will have to take it up with your managed server provider.

@Buzzer1977@Porkbrain If changing the DNS server doesn't fix it for you or is not an option, the alternative would be adding 185.195.197.4 api.digitalcombatsimulator.com to C:\windows\system32\drivers\etc\hosts as a selective, temporary workaround described here in more detail. Make sure to undo it though, once a hotfix is out.

It is (DCS fails to resolve api.digitalcombatsimulator.com). ED are working on a proper fix. Changing DNS server typically resolves it. If it doesn't, editing your etc/hosts is another temporary workaround. More details here:

Recently stumbled over the DCS.getConfigValue() function while digging inside DCS' Lua guts. The undocumented function will read values from the "config" Lua environment/state (net.dostring("config", ...)), e.g., values set in autoexec.cfg. As this enables much simpler configuration than setting environment variables, I've modified NoErrPopup.lua to use it. Thus, the optional configuration is now handled via autoexec.cfg. Updated the first post accordingly. Also removed the attachement and linked to the script on my Github account, to facilitate minor updates.

Recently stumbled over the DCS.getConfigValue() function while digging inside DCS' Lua guts. The undocumented function will read values from the "config" Lua environment/state (net.dostring("config", ...)), e.g., values set in autoexec.cfg. As this enables much simpler configuration than setting environment variables, I've modified FPSmon.lua to use it. Thus, the optional configuration is now handled via autoexec.cfg. Updated the first post accordingly. Also removed the attachement and linked to the script on my Github account, to facilitate minor updates.

@Clawhammer Great use of the resource monitor The .miz mission file is presumably fully loaded into memory. I'd be more worried about object models that will only be loaded once new units spawn, terrain sections that will be loaded when units enter the area (like Clawhammer just showed), etc. Opting for an NVMe SSD will give you the peace of mind that you're using the best tool for the job at hand. I've written a small script for server performance monitoring, which will warn you via global chat if the server performance deteriorates. That will at least warn you if the server performance is becoming problematic.

TL;DR: Considering current NVMe SSD prices, everyone recommends against HDD use.

The newest DCS update to 2.9.13.6816 brought a significant change to a_do_script(): This newly introduced return value pass-thru obviates the workaround I had implemented to get return values from a_do_script() via a temporary file. This implies that modification of MissionScripting.lua is no longer necessary. You may remove the modification manually or by repairing DCS via the updater. As a pleasant side-effect, installation is now significantly easier. Drop WebConsole.lua in the Scripts\Hooks folder and you're set. I also improved the description for clarity.

@aterfax: I've figured out how to install DCS without innoextract'ing the updater and how to get SRS up and running. Also set DCS and SRS up as systemd units that support multiple instances. Have a look and give me a shout. I would like to collaborate on this.

TL;DR: Currently experimental git repo of configs and scripts intended to automatically install and manage multiple DCS and SRS server instances on a single headless Linux server using systemd. I've been using the code to run a dedicated DCS server along with an SRS server for a couple of months. It's been smooth sailing from DCS 2.9.9 all the way thru 2.9.14, so I'm releasing this into the public to get some feedback. Please do not hesitate to ask any questions in this thread and also feel encouraged to create issues or pull requests on Github. Features Fully automatic installation and upgrades of DCS and SRS Plug & Play: DCS and SRS are usable immediately after installation Pre-configured with reasonable defaults Auto-starts a default mission (Caucasus with dynamic spawns) Ships with useful helper scripts Minimal overhead: ~200M RAM on Debian 12.9 (kernel + user-space) Built for headless (non-GUI) Linux servers: Does not require a desktop environment (e.g., Gnome, KDE, XFCE, ...) DCS and SRS windows accessible via VNC (serves minimal GUI) Runs Caucasus, Marianas, and Syria on servers with 16G RAM (other terrains unverified) Convenient management of all server processes through systemd user services (systemctl --user start|stop|status dcs-server|srs-server) and automatic restart of failed services (to the extent DCS enables it ...) Supports multiple DCS server instances (DCS_server.exe -w DCS.*) through systemd unit instances Installation Instructions Check the README.md. Screenshot

As of DCS 2.9.13, a_do_script() finally has return value pass-thru: Example code for the control/hooks environment that fetches a string value from the mission scripting environment: return net.dostring_in("mission", [=[ return a_do_script([[ return "42" ]]) ]=]) P.S.: Sorry for necro-posting. As these forum posts are DCS' scripting "documentation", it appeared appropriate to update said docs.

As of DCS 2.9.13, a_do_script() finally has return value pass-thru: Example code for the control/hooks environment that fetches a string value from the mission scripting environment: return net.dostring_in("mission", [=[ return a_do_script([[ return "42" ]]) ]=]) P.S.: Sorry for necro-posting. As these forum posts are DCS' scripting "documentation", it appeared appropriate to update said docs.

Absolutely. My intent was not to push it. Just posted my report here to inform the other players affected by this.

@SKYWARRIOR: Only editing etc/hosts as suggested by OP and explained here by me must be reverted once a fix is out. You can keep using the Google DNS indefinitely without fear of it breaking DCS in the future*. *) Off-topic: There are however pros and cons to using Google DNS. I personally use Quad9 with encryption, as I value privacy over raw performance.

Thanks. I really do consider this a crash-like situation, as the game decides to intentionally terminate itself, for no logical reason whatsoever. While IMHO still entirely unreasonable(!) from a usability and stability perspective, it would have made more sense to terminate when losing the master server connection. However, terminating when regaining the master server connection appears so extremely illogical that it can only be a bug*. Hope the Devs agree *) Even for an always online title, which DCS -- fortunately -- is not, termination after successful reconnection and reauthentification would not make sense, unless its intent were purely punitive in nature.

Absolutely. Exactly for that reason the DCS client should handle that situation gracefully and not just boot people from their game. I've investigated, reproduced, and reported the underlying issue for DCS version 2.9.13.6818. This wishlist item contains additional information when and how it occurs:

TL;DR: The DCS client/server terminates with a "Login session has expired" error popup only when reconnecting to the DCS master server after the connection had been lost for 30+ minutes. No error occurs, if the connection stays lost. This makes no sense and harms user-experience unnecessarily. The termination also occurs with the same error popup for a variety of other reasons. Technical Details The DCS client* must authenticate with the DCS master server (api.digitalcombatsimulator.com) when starting. As part of a successful authentication, the client will receive a temporary session ID from the master server. The client uses that session ID to periodically check with the master server every ~10 minutes. Clients and master server communicate via encrypted HTTP. The periodic session check is an HTTP POST request to which the master server normally responds with status code 200 (OK). *) Here and subsequently, "client" refers to a client of the master server. This includes the DCS dedicated server, which also performs authentication and periodic session checks with the master server. The master server session cache expires within ~30 minutes: If the master server has not received session checks from a client for ~30 minutes, it will forget the respective session ID. Afterwards, the master server will respond with HTTP status code 401 (Unauthorized) to any session check from a client with an expired session ID. This will be logged in dcs.log as: 0000-00-00 00:00:00.000 ERROR ASYNCNET (0): HTTP request dcs:checksession failed with error 28: Timeout was reached 0000-00-00 00:00:00.000 WARNING ASYNCNET (0): Session check failed: -28 0000-00-00 00:00:00.000 ERROR ASYNCNET (0): The session has expired (401). Exiting... The affected DCS client will not try to reauthenticate, but instead terminate with a "Login session has expired" error popup: This issue is likely not restricted to re-establishing connection with the master server and HTTP error 401. Other master server-side errors trigger the client-side termination, too. If the master server (or the reverse proxy it resides behind) temporarily responds with other error codes, e.g., 502 Bad Gateway, the client terminates itself, too. While I've not experienced this particular error code myself, it's been reported here. Apparently, this issue also occurs entirely out of the blue without any prior connection issues (i.e., no session check errors/warnings, cf. above) in dcs.log [1]. According to BIGNEWY, reasons may include simultaneous logins with the same account, local internet issues, or changing IP addresses [1, 2, 3, 4, 5]. However, I've not been able to reproduce this by repeatedly changing public IP address during a DCS session and local internet issues causing failure to connect to the master server would result in session check failed messages in dcs.log. So with the noteworthy exception of simultaneous use of a single account, I see no reason why this issue should occur. This might even be a bug in the master server. Who is Affected / Why to Fix This All players and servers: If the master server goes down and forgets all session IDs, all clients and servers will be forcibly terminated, too. This has happened on multiple occasions. Either scheduled or repeatedly unscheduled [1, 2, 3, 4]. This issue frustrates customers. With the master server being a single point of failure, this presents a possible attack surface. I'll refrain from elaborating on this further to not give random script kiddies any bad ideas. Players with a spotty internet connection (to the master server): Spotty internet connections are hard to debug and even harder to fix. Even if everything else works (e.g., playing DCS in multiplayer, streaming, downloads, etc.), an ISP's route to the single DCS master server may be sufficiently congested to affect the periodic session checks temporarily. Whereas DCS updates/downloads are handled via a globally distributed CDN, there's a only one master server that is located in Europe (ping/traceroute api.digitalcombatsimulator.com and cdn.digitalcombatsimulator.com for comparison). Players complaining about this in the forum are typically referred to customer service. A proper fix may pay for itself by less customer service tickets. I'd also expect far more players to be affected than there are reports on the forum [1, 2, 3, 4]. Casual single players or mission editors who want to suspend their computer mid-mission to resume another day: Suspending your computer for more than 30 minutes will also result in forced termination. With the DCS save feature not yet capable of resuming complex missions, this is a valid use case for casual DCS players. Workaround (@Affected Players) As the DCS client only terminates after reconnecting to the master server, the termination can be inhibited by preventing the reconnect. Do this at your own risk: Start DCS. Once in the main menu, the mission editor, or on a multiplayer server, inhibit further communication with the master server (api.digitalcombatsimulator.com), e.g., via firewall rules or by adding an invalid IP route with an administrator PowerShell: $api_addr = (Resolve-DnsName api.digitalcombatsimulator.com).Address route add $api_addr/32 0.0.0.0 Go about your day, suspend/resume your computer, or connect to multiplayer servers via IP address. The multiplayer server browser will no longer work. After closing DCS, remove the firewall rule or the invalid IP route: route delete $api_addr/32 0.0.0.0 How to Fix This (@ED) This issue could (and should) be addressed both at the client and the master server: The master server session ID cache should not expire prematurely. Using the 72 hours saved authentication grace period for expiring sessions seems reasonable. This fix should be relatively straightforward to implement as a stopgap measure. Improve client error messages. The session expiration presumably occurs for a variety of reasons, but the client always shows the same generic error popup message. To simplify debugging, the client popup message and dcs.log should include a human-readable explanation of the specific reason for the session expiration. This would require support from the master server, which must include this reason in its response (e.g., as the response body with a text/plain Content-Type; currently the 401 responses are text/html with an empty body). The client (and dedicated server) should always attempt to reauthenticate with the master server instead of just quitting immediately after a failed session check. Silently start the 72 hour saved authentication grace period once the connection to the master server is lost (or the master server experiences server-side errors, i.e., 500+) and only terminate the client if the master server hasn't been reached within that duration. Reset the grace period once the connection to the master server has been re-established. That should balance between user-experience (which ultimately pays ED salaries) and software piracy concerns. How to Reproduce Start DCS (in Online Mode), open the Mission Editor. Wait a minute. Disconnect DCS from the master server api.digitalcombatsimulator.com (185.195.197.20). Either by disconnecting from the Internet, by using a firewall rule for the aforementioned IP, or by setting a non-existing network route via a PowerShell with administrator privileges (alternatively, you can also just suspend your computer): $api_addr = (Resolve-DnsName api.digitalcombatsimulator.com).Address route add $api_addr/32 0.0.0.0 Keep DCS disconnect from the master server for 30+ minutes (less may suffice, too, but AFAICT it needs to miss more than just one session check). Re-enable the connection to the master server. If you used the route method, delete the invalid route: route delete $api_addr/32 0.0.0.0 Wait for DCS to quit within the next minute or so. Edit: Updated post, added workaround. Original post in below spoiler.

When starting DCS while the master server is unreachable it will fall back to offline mode with the saved authorization from a recent login. However, attempting to switch to online mode from the main menu will toggle the icon and shortly after close the game. According to dcs.log, leaving offline mode succeeded (even with an unplugged Ethernet cable ...) but then the game closes without logging an actual error (excerpt, full log attached): 2025-02-25 07:39:07.480 INFO ASYNCNET (Main): Successfully left the offline mode. 2025-02-25 07:39:07.491 INFO EDCORE (Main): (dDispatcher)enterToState_:5 2025-02-25 07:39:07.524 INFO APP (Main): application shutdown Steps to reproduce: Disconnect your Internet Launch DCS Acknowledge the popups Press Online Mode in main menu dcs.log

Glad to hear that. Just make sure to undo the workaround after a fix is out! Otherwise, it will come back to bite you, when you least expect it. This would be an absolute nightmare to debug, when you don't know anymore where to look.

@N0XID: Looks like you're running your servers via Wine, presumably aterfax' Docker. If so, the following shell snippet should configure a workaround for you (subject to the side-effects I pointed out before): echo "185.195.197.4 api.digitalcombatsimulator.com" >>~/.wine/drive_c/windows/system32/drivers/etc/hosts

Works as of 2.9.13.6818 on Windows 10. Note that "silent" implies automatically uploading the crash report: @BIGNEWY: Is there an option to disable the automatic upload? Tried "disable", "disabled", "no", "none", and "off" to no avail. Anything but "silent" will open the DCS Crash dialog.

The dedicated server is also affected (same lua.dll, presumably). The code does not cause a segfault with server version 2.9.12.5336. Server crash trace: dcs.20250224-092739.crash

This is an awesome, albeit belated, feature addition! Any documentation available on this? What's the function signature? I just toyed around with it and managed to crash DCS (segfault).