Actium

Are you using a separate server account? AFAIK, no more than 3~5 server instances are allowed to run on the same account. The error codes given in the DCS log are HTTP response status codes, with 401 meaning Unauthorized. I'd be curious about the communication with the master server when that error happens. If you'd like to dig into it, you'd have to resort to sth. like sslsplit to intercept the communication between your dedicated server and the ED master server.

@Arcc You need to run the following in a command prompt to downgrade to a specific DCS version: cd C:\Program Files\DCS World OpenBeta bin\DCS_updater.exe update 2.9.13.6818.2 Adjust the path after cd to your DCS installation folder. Alternatively, download dcs_downgrade_2.9.13.6818.2.bat.zip, unpack it into the DCS installation folder, and run (double click) the .bat file. P.S.: You should never run any .bat files that strangers tell you to run without checking them first (right-click -> edit will show that it contains just above DCS_updater.exe command).

The steps to reproduce from my first posts still trigger the crash on both client and dedicated server. dcs.20250320-214042.crash

This issue has been fixed in DCS 2.9.14.8222. Unserializable values will now be substituted with null. The following example code local t = {a = 1, b = 2, d = 4} t["c"] = t return net.lua2json(t) now returns {"a":1,"d":4,"c":null,"b":2}.

@Flappie While said former issue has been fixed with 2.9.14.8222, above issue is still present.

https://en.wikipedia.org/wiki/Nothing_to_hide_argument

NOTE: This does not apply to you if you first installed after the 20th of March 2025. The login failure bug has been fixed by 2.9.14.8222 (absent from the changelog). The previous workaround (adding 185.195.197.4 api.digitalcombatsimulator.com to etc/hosts) is now a liability that will break the login if the master server ever changes its IP address. I've modified install_dcs.sh to remove the workaround. Either re-run the updated install_dcs.sh or execute the following code from a terminal to undo the workaround: WINE_ETC_HOSTS=${WINEPREFIX:-$HOME/.wine}/drive_c/windows/system32/drivers/etc/hosts if grep -q "^185.195.197.4 api.digitalcombatsimulator.com" $WINE_ETC_HOSTS ; then sed -i "/^185\.195\.197\.4 api\.digitalcombatsimulator\.com/d" $WINE_ETC_HOSTS fi

It is indeed multi-threaded, as it does use multiple threads. However, as I wrote previously, the main thread is the apparent bottleneck, which uses up considerably more CPU cycles than all other threads combined. On a multi-core CPU, that will result in a low overall CPU usage. See this Process Explorer screenshot (right-click DCS_server.exe -> Properties):

It has, albeit at a low level. See the monthly steam user survey. With most Windows users being thoroughly vendor-locked and also not giving a damn about privacy (most people use Edge or Chrome, signed into personal accounts), I doubt this will change in the foreseeable, but it shouldn't shy the enthusiasts away from breaking it off with Windows.

Thank you! No, not yet. I'm still in the process of stabilizing the foundation. There's still a few issues I'd like to have ironed out before adding on features (e.g., automatic DCS updates, adding/configuring more server instances, installing/removing terrains, extended README.md). The ecosystem of DCS mods, bots, various tools (e.g., Olympus) and mission frameworks (e.g., Retribution, Liberation) is also so comprehensive that it's beyond the scope of this project to support them all. I will have to prioritize everything that enjoys widespread and universal use, e.g., Tacview. In terms of a roadmap, server performance is my next big objective. I'm in the process of experimenting with a recent improvement in both the Linux kernel and Wine (called ntsync) that will hopefully bring a significant performance improvement.

Dedicated server? I've tried to write a clear and concise README.md for my non-Docker installation method. Let me know in this thread if anything is unclear or missing. @aterfax created a video for the Docker install. I haven't tried installing the DCS client on Linux, but if you need some info, you may find it in this TDCS thread. There's also a bunch of videos on Youtube, but for lack of having tried it myself, I cannot endorse any. UPDATE: Just recalled the DCS_Standalone_on_Linux git repo that also appears current and quite detailed.

The dedicated server actually runs nicely on Linux (via Wine). Only recent hickup was ED's DNS resolution experiment that backfired (and has been waiting to get fixed for 4 weeks). I'd even go as far as claiming that installation and setup is actually easier on Linux than on Windows: On Linux, it works (fully) automatically either using Docker or natively. Performance on Wine is not quite on par with Windows, but I'm hopeful that ntsync will improve that in the foreseeable future. I'll post some benchmarks once I've found the time to build Wine 10.0 stable with the ntsync MR applied. As the dedicated server runs fine as-is on Wine, I'd rather ED use their time to fix the many bugs and inadequacies of the server before attempting to port it to Linux. The dedicated server is just a stripped-down client with all the baggage that comes along with it: It is made for interactive use and thus unreliable when used non-interactively. In fact, it bricks itself when anything goes awry. The ED master server is unreliable and a single point of failure. Servers randomly go missing from the server list. I'm sure the list of problems goes on. Of course, reports of these issues go unacknowledged.

@Clawhammer Thanks for testing and reporting your results.

Implemented password protection (HTTP Basic authentication) to improve security on multi-user systems. Configure a strong password in autoexec.cfg to prevent other users on the same computer from exploiting WebConsole.lua to execute arbitrary code from your user account. HTTP Basic authentication is unencrypted and only provides security for sockets bound to localhost. Do not use it to access the console remotely over network! First post updated accordingly.

@Toumal Just pushed a watchdog that'll query the WebGUI port and force a server restart if it fails to response. Also figured out that the server will keep responding normally even with a frozen simulation (infinite loop in onSimulationFrame()), unless queried with a valid encrypted request.

@Toumal Possibly of interest to you: Systemd user unit file to run and automatically restart a DCS server. More details on the whole work-in-progress thing in this forum thread (same link as above). Let me know if you have any comments on it. Thanks! Love the idea! Guess I'll write another systemd service that'll supervise the server that way. Before, I have done it the crude, hard, and brittle way by querying the game port instead of the webgui port : #!/usr/bin/python3 import socket sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.sendto(b"\000\222\274\330S\n\241\016u\233,\3325\256o\371;\304\261;Sa\213\205{\000'\252\334d\355", ("127.0.0.1", 10308)) print(sock.recvfrom(65536))

Same recommendation as for your other issue: Enable debug logging, check the contents of dcs.log, compare logs with a local dedicated server install using the same config and steps.

Does Fox3 provide access to dcs.log? Preferably, with full debug logging enabled. If so, please restart the server (so you start with an empty dcs.log), document each step you take to reproduce the issue (with as few steps as possible), and post the dcs.log along with the exact steps that produced that log. The (debug) log should be considerably more informative than screenshots. Absolutely. But that goes both ways. Therefore, I'd recommend you to install a dedicated server on your local computer*, apply the exact same configuration you use on the Fox3 server, try to reproduce the issue you have with your Fox3 server on the local dedicated server install, using the exact same steps. Finally, compare the logs to narrow down the cause of your issue. Best of luck and please report your findings here!

@ToumalCould you elaborate a bit on what exactly you do for these checks, please? I was wondering how to detect a bricked DCS_server.exe for the purpose of terminating and restarting it. I've though of a simple Python script that periodically polls the server status via its UDP query protocol and shoots it down if it fails to respond for a couple of times (got a working proof-of-concept). As I host my dedicated server on Linux, I also considered using some dark magic (swaymsg -t get_tree) to periodically check if DCS_server.exe opened any popups that would qualify it for immediate termination.

Absolutely. The DCS updater allows downloading all files without login anyway, so I see no reasonable justification to intentionally restrict the dedicated server to not start without login. It does not prevent software piracy at all. Of course, I'd be happy to learn about any logical reason to keep the login restriction (and the annoying issues it causes) in place. However, I have a practical explanation: The dedicated server code base likely borrows largely – if not entirely – from the client. You can deduce that from the dedicated server's log messages: 2025-03-03 22:25:33.969 ERROR EDCORE (Main): No suitable driver found to mount bazar/textures/f-15 It attempts but fails to load a bunch of textures, although a dedicated server would never need any textures for lack of rendering. Deriving the dedicated server from the client makes sense from the narrow perspective of code maintainability: It limits the overall amount of code. The unidiomatic login necessity, login error popups, and the mission scripting error popup are presumably just leftovers from the client. Obviously, the slightly simplified code maintenance comes at the cost of added support effort, with the latter probably outweighing the former. It shouldn't be too troublesome to #ifdef the entire login code to only be included in the client and not in the dedicated server. But that would be sth. for the DCS Code Wish List. I see no reason to invest time advocating for that change as long as the described dedicated server usability bug goes unacknowledged and the far more serious Login Failure remains unfixed for 2 weeks as of now.

@Maverick87Shaka I took the liberty to file a bug report related to this. Not regarding the sometimes unreliable master server itself, but instead about DCS_server.exe bricking itself when it happens:

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.