Some instances wouldn't start after updating.
I discovered after updating to 188.8.131.52759@openbeta that instances wouldn't start and I wasn't able to properly address for a couple of days. Apologies for any frustration and thanks for bearing with me. This blog post is a bit of a post mortem.
It was a bit confusing. I noticed there was an issue when testing the update in Sydney and the mission took longer than usual to start. From the DCS logs it appeared that DCS was getting stuck logging in. Testing startup in other regions had mixed results. Sometimes missions would start without issue, and other times it would stall in the same place. Where DCS startup had stalled I connected via RDP and tried to observe the startup issue by killing the DCS.exe process and restarting, but that always resulted in a normal startup. So I haven't been able to identify a cause. I'm not sure if 184.108.40.206759@openbeta introduced the behaviour, if the behaviour was already there and just became more prevalent, or if I've introduced something due to how I update or start DCS.
DCS log - login
A hurdle when automating DCS Dedicated Server is logging in. The launcher does automate this process on subsequent starts, but when running on dynamically provisioned EC2 every start is a first start. The launcher accepts the login via a dialog which is a little awkward to automate. On Windows the mechanisim I use is SendInput (winuser.h), and on Linux I use xdotool.
I've decided to just accept that DCS won't reliably start. To that end I've just added a strategy that restarts DCS.exe if the 'Login success' message doesn't make a timely appearance in the DCS log.