zhliau / fika-headless-docker

Docker image to run SPT + Fika client headless, to provide a packaged dedicated client for raid hosting
Other
16 stars 6 forks source link

Add wineboot --update on startup. #14

Closed robpneu closed 3 days ago

robpneu commented 3 days ago

I did a pinch of debugging (changed WINEDEBUG=-all to WINEDEBUG=warn+all and looked through the mounting of logs that came out as a result). I found that the 5 minute delay at boot when is caused by it hanging on wineboot. It does a bunch of setting up, then just sits, and then after almost exactly 5 minutes (+/- 10 seconds) the error run_wineboot boot event wait timed out comes up, which is descriptive enough to indicate it was the cause of the 5 minute delay, so I went looking for how to resolve that.

My bit of research said that just running wineboot --update fixes that error, and that held up in my testing.

It takes maybe 10-20 seconds to run but in my testing it brings the overall time from cold boot (no container) to WebSocketHandler "FikaDedicatedRaidService" connected appearing in the backend logs to 30-60 seconds.

I sent the output to a log file because it outputs a bunch that most people won't care about or want in their main logs.

Sources

zhliau commented 3 days ago

Just testing this now and interestingly, wineboot complains a lot about a missing display, but if you try to provide Xvfb to it either by running xvfb prior to the wineboot call or by using xvfb-run -a it actually makes the boot time way worse.

Your PR seems to shave the container boot time from 5 minutes to ~60s, great work! I just left one comment, after it's addressed I'll merge and make a new release.

robpneu commented 3 days ago

Just testing this now and interestingly, wineboot complains a lot about a missing display, but if you try to provide Xvfb to it either by running xvfb prior to the wineboot call or by using xvfb-run -a it actually makes the boot time way worse.

Oh yeah, I saw that as well. I should have noted that was why I made it be the first thing that runs in the entrypoint.sh. I also tried having it be run at the end of the docker image creation itself (ie in the Dockerfile) but it didn't seem to solve the issue when it was run there and I didn't spend much more time trying to figure out why.