Image corruption
wavemaster447 opened this issue · 3 comments
I'm finding that on 2 of the 8 machines I've pulled the image on, I have consistent file corruption issues with some map or resource. Forcing an integrity check with docker save cm2network/tf2 > /dev/null will yield some broken resource, or the connecting TF2 clients will see Your map (map_name.bsp) differs from the server's or some similar error. I'm not sure what will cause these issues, but on the machines it appears on, some resource will consistently error every time I purge and re-download the image, infuriatingly a different resource every time. Docker doesn't throw any errors with the pull, it only discovers issues after forcing a check.
All 8 machines are Ubuntu 18.04 LTS, the only commonality I can see with the 2 erroring machines is that they are physical boxes, rather than VPC's or EC2 instances.
I think I've fixed the issue on each machine by entering the Docker container, reinstalling steamcmd and forcing a verify-and-update of appid 232250, but it was a messy process.
Is anyone else seeing these same issues? Is there a way to package steamcmd in a way that the "validate" command can be run without needing a reinstall?
Hey @wavemaster447,
I can't exactly explain why the image should corrupt itself, but I'm about to rebuilding the image in similar fashion to my csgo image (download the required files on first startup of the container instead of delivering them in one big image). Maybe a fresh download directly to disk could be a solution for the problem...
I can't think of a reason why a physical machine would be more susceptible to corrupting the installation, but I'm intrigued by the error. Are there any other differences? For example are the physical upgraded (software-wise) to the same level as the EC2 instances? Because I assume you probably rotate the (cloud-based) EC2 instances so their OS images will get updated, whilst the physical ones will need manual upgrades.
Are there maybe hardware differences (HDD vs SSD)?
Thanks @CM2Walki - that rebuild makes a lot of sense, Steam seems to have more robust file validation than Docker does (to my surprise). Everything is fully up-to-date though it's a good point that the baremetal machines are certainly older than the hardware I imagine EC2 is emulating. Everything is SSD - I ran a badblock check after you suggested that but it seems all clear.
While I have you, thought I might make a "feature" suggestion for the readme, to help less experienced docker users edit the server config - you can offer a copy-paste exec command to help edit the server.cfg, especially if you package nano into the image:
docker exec -u 0 -it tf2-dedicated nano /home/steam/tf2-dedicated/tf/cfg/server.cfg
will instantly pull up the cfg for editing, without people needing to understand how to "enter" a container.
Hey @wavemaster447, I applied the changes from CM2Walki/CSGO to the TF2 image, it should now download the server on first launch. I think that should mitigate the problem. Can you test it out and see how it goes?
While I have you, thought I might make a "feature" suggestion for the readme, to help less experienced docker users edit the server config - you can offer a copy-paste exec command to help edit the server.cfg, especially if you package nano into the image:
docker exec -u 0 -it tf2-dedicated nano /home/steam/tf2-dedicated/tf/cfg/server.cfg
will instantly pull up the cfg for editing, without people needing to understand how to "enter" a container.
I like everything about it except for the fact that a text editor would need to be included in the CM2Walki/steamcmd image. However, given the fact that nano would be around 2 MBs it should be fine. That's a small price to pay for a good quality of life change :).