Inland-Empire

Is it normal for supervisord.log to acknowledge it bound an incoming port about once or twice a minute indefinitely after starting the container? My log looks like this (port redacted): 2024-01-01 12:07:03,445 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****' 2024-01-01 12:07:48,707 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****' 2024-01-01 12:08:33,995 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****' 2024-01-01 12:09:19,240 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****' 2024-01-01 12:10:04,536 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****' 2024-01-01 12:10:49,741 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****' 2024-01-01 12:11:35,078 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****' 2024-01-01 12:12:20,284 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****' 2024-01-01 12:13:05,585 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '1*****'

I've noticed a huge amount of writes, particularly to docker.img, coming from my Pi-Hole docker. They're easily several orders of magnitude more frequent than any of my other containers. Any idea what that could be?

While searching, I did find a comment you made some time ago where you mention configuring your containers so that no information from them is saved to docker.img. Since I think it's possible docker containers are pushing data to that .img, how did you divert where information headed there is saved?

I've done further digging over the last week and haven't found any posts about the specific phenomenon I'm talking about. There appears to be plenty of discussion on appdata writes from docker containers, but nearly all the writes I'm seeing are actually caused by docker.img itself on the system share on my cache drive. When using inotifywait on appdata, I saw a fair amount of activity, but most of it did not align with the cache writes I was seeing. I instead opted to try running inotifywait -r -e modify,delete,create,close_write -m /mnt/cache which is when I discovered that the vast majority of write activity is listed as /mnt/cache/system/docker/ MODIFY docker.img This is strange to me, and I'm looking for more information on what could be causing these constant docker.img modifications. Does anyone know how I can reduce this activity?

Presently, my appdata, system, and domains shares are on my 1TB NVMe cache drive, formatted in btrfs. When Docker is set to enabled on my machine, I get consistent pulses of writes to the cache, even when zero containers are active or running. This happens in the high KiB to low MiB range once every 5 to 30 seconds. My File Activity plugin displays no activity when this happens. I am running Unraid 6.12.4 Since these writes are unnecessary and add up over time, I would like to identify the cause and prevent them from happening. Does anyone know how to address this problem?

Thanks for your quick response! I discovered it was a permissions issue after moving my appdata folder to a new nvme cache drive. I resolved the problem by uninstalling the container, then deleting the steamcmd and tf2 folders using midnight commander. After that, I simply reinstalled the docker container and it ran perfectly first try.

I installed ich777's TF2 docker container but can't get the server to start. Any time I attempt to run the container, I get the following result: Connecting anonymously to Steam Public...OK Waiting for client config...OK Waiting for user info...OK Success! App '232250' already up to date. ---Prepare Server--- mkdir: cannot create directory ‘/serverdata/.steam/sdk32’: No such file or directory cp: target '/serverdata/.steam/sdk32/' is not a directory ---Server ready--- ---Start Server--- WARNING: No map specified! Server may not heartbeat. Auto detecting CPU Using default binary: ./srcds_linux Server will auto-restart if there is a crash. Setting breakpad minidump AppID = 232250 Using breakpad crash handler dlopen failed trying to load: /serverdata/.steam/sdk32/steamclient.so with error: /serverdata/.steam/sdk32/steamclient.so: cannot open shared object file: No such file or directory Looking up breakpad interfaces from steamclient Calling BreakpadMiniDumpSystemInit I'm almost certain the issue is related to the "cannot create directory" problem, but no amount of googling or trial and error has gotten me any closer to a solution. Does anyone have any idea what to do?