DockerBubba
-
Posts
20 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by DockerBubba
-
-
With respect to the /dontstarve/token directory, what is the default install structure?
My friend's is completely different than mine with a separate uniquely-named folder and two(!) copies of the Cluster_1 directory and three instances of cluster.ini! BUT, it works on my server!
My structure is:
/dontstarve
- /token
-- /Cluster_1
--- /Caves
--- /Master--- adminlist.txt
--- cluster.ini
--- cluster_token.txt
Follow-up: My friend was just messing around with "backup" directories, but, regardless, when I copied his /dontstarve folder to my /appdata and changed the cluster.ini to my settings, it works perfectly, no duplication!
Is there an easy way to force-install a completely clean /steamcmd directory? I guess you could shut-down your Steam-related apps, delete /steamcmd and then install something completely new and that should re-create it? -
1 hour ago, ich777 said:
I will try it when I got home from work on my server and report back.
From what I see in the logs everything looking good for the Caves and Overworld, maybe some setting was changed so that the Caves are now a separate Dedicated server?
The default settings that I ship the container with are that a cluster is created and both the Overworld and the Caves are started as two separate instances but are only visible as one, however if something was changed in the config that no cluster is created it is possible that you see two instances running.
Hope that makes sense to you.
Will get back to you when I've tried it on my server.
I just removed and re-installed the instance (making sure to completely delete the /dontstarve folder prior to re-install, again)
This time, I'll add the token and make incredibly minor changes to the cluster.ini, like just the name and password, even though hardly anything else was changed in any case.
Follow-up: Nope, same thing... Completely vanilla install, only changed the game name, password and type (game type made no difference in the past).
There are really only two possibilities:
- the /steamcmd directory holds something that is messing it up- the cluster token is somehow messing it up
Hmmm...
Follow-up #2: Tried a cluster token from a friends server, no difference, still two joinable games show-up (yes, he shut-down his instance!
) This time, I changed the game name and password ONLY!
-
21 minutes ago, ich777 said:
You have to wait, a long, long really long time and after that you can pull the log, Firefox actually doesn't crashes.
The install is pure vanilla from the Docker repository, with only minor changes to the cluster.ini for name, game type, etc.
Anyhoo, here are the two log files from a clean-start... -
cluster_token.txt
6 hours ago, ich777 said:This is really strange... Is one maybe for the Caves or did you deactivated the Caves?
Can you restart the server and send me the log output please after restarting the server until it's fully started?
Are the logs stored somewhere in the /dontstarve folder? The unRAID log window always slows down Firefox and will sometime crash!
Also, I found the the instructions vague and process to make, the cluster_token.txt file, incredibly convoluted. There wasn't any clear direction that it must come from the LOCAL (PC) client and that you also need to have a fully logged-in Klei account for it to generate. Seeing how I've already tried wiping and re-installing the entire unRAID /dontstarve directory, maybe it's a corrupt cluster_token.txt?
-
This is weird... I've asked on the Klei forums and got nowhere, but any ideas why my Don't Starve Together unRAID instance is creating TWO distinctly separate worlds to join? They share the same preferences as set in the cluster.ini (game type, name, password, etc.)
In the attached images you'll see that one is on Day 33 and one Day 9; both completely playable!
-
7 hours ago, ich777 said:
Can you please try to upgrade to 6.9.2, I think that should resolve the issue because the Valheim container got updated and it is related to the way older Kernel version from 6.8.2
Wooooo! That seemed to do the trick!
The log is behaving normally and it looks like it's installing (7 Days to Die)
So, YES, update to 6.9.2 ASAP! That said, the Community Applications "homescreen" seemed to die after an update, but you can still search and install.
-
1 hour ago, stryder said:
Getting an issue with my Valheim servers: /opt/scripts/start-server.sh: line 240: /serverdata/serverfiles/valheim_server.x86_64: No such file or directory
I have cleared all appdata directories and SteamCMD, as well as redownloading the container from CA and still get this after it finishes downloading and tries to start.
Eventually it'll throw this error: src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize.
My SteamCMD path is correct in the config, as well as the ServerFiles.This started a couple weeks ago with servers that were previously working.
Any thoughts?
This is EXACTLY what is happening to me... There has been some kind of recent change in either Unraid, docker or maybe the way the gameserver dockers work now. It had been working flawlessly for more than a year now and its all gone to crap!
-
OK, I have no idea why a 7DTD update would cause so much grief!
Now it seems that the 7DTD process has filled-up the Docker image itself, which should be impossible, no? The Docker volume and log were at 100%, so I did a purge and rebooted, but now the very first line in the log is:
"/tmp/dumps insufficient permissions - delete and recreate" -
1 hour ago, ich777 said:
Have you changed the path to the appropriate disk in the template?
As said above SteamCMD is only called when the container is started so you can do whatever you want when all containers are fully started or stopped.
When you choose and run the 7DTD container from Community Applications (using defaults), it DOES manage to make three empty directories, where you would expect them to be, so I don't think it's any kind of disk access issue.
-
38 minutes ago, ich777 said:
You don't have to shutdown the other containers.
SteamCMD is only used/updated when a container is started/restarted.
There is something wrong on the system itself it seems to me if you get this error.
On what hardware/unRAID version are you running the game servers?
Have you double checked that all files are on one disk and not spread across multiple disks?
There's only one drive attached to the system!
I'll fire-up the other steam-centric containers again and then delete /steamcmd and re-try 7DTD. -
48 minutes ago, ich777 said:
Can you point me to this threads/posts where people run into this?
With Satisfactory it's a completely different story because this is related to older AMD CPUs who doesn't support some instructions that are necessary on for example the experimental branch.
Why should this be related?
Delete them if you want to but that won't change anything and will make bo difference at all.
Have you yet tried to reinstall the container (delete the container, delete the 7dtd folder and pull a fresh copy from the CA App)?
Also don't forget to set your appdata share to use cache "Only" or "Prefer".
As said above the container works fine and also on many other systems, this is the first time that I hear about that error on unRAID, maybe @Spectral Force heard of that but I don't think so...
Yes, the first thing I did was delete the container, delete the /7dtd directory and it made no difference.
By the sounds of it, it's a steamcmd problem, not necessarily related to your 7dtd container. With that in mind, if I shut-down the other Steam-centric containers, can I delete the steamcmd directories and try to re-install 7dtd from scratch? Will that effect the other game servers that use steamcmd?
Waay at the bottom of this thread is where I found a reference to the exact issue:
https://githubmate.com/repo/MitchTalmadge/AMP-dockerized/issues/94
-
Any more insight on this error issue with the 7 Days to Die container deployment:
"src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize.src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize."
It's obviously a rare issue, but a couple of people running Unraid have ran into it, more importantly, on Satisfactory, not 7DTD, so it might be some broader issue.
A friend suggested it might have to do with the optional Steam login fields, but are those ever relevant? -
1 hour ago, ich777 said:
I also now tried and have no issue whatsoever, do you run AdGuard or PiHole somewhere on your network?
It seems like something failed with the download of certain files. Are there any files in the '7dtd' folder?
Also here is the log from a newly installed instance on my server: 7dtd.log.txt
Please try to start over by deleting the container and the 7dtd folder that lives in your appdata directory and pull a fresh copy from the Container from the CA App.
No, it's a pretty vanilla Unraid setup, but this first part of the log (which acts very odd, overwriting itself and not clearing from previous attempts) and it has an error right away: "deadlock "?:
---
---Checking if UID: 99 matches user---
---Checking if GID: 100 matches user---
---Setting umask to 000---
---Checking for optional scripts---
---No optional script found, continuing---
---Starting...---
---Update SteamCMD---
Redirecting stderr to '/serverdata/Steam/logs/stderr.txt'
src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize.
[ 0%] Checking for available updates...
Thread failed to initialize
src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize.
Thread failed to initialize
---Update Server---
Redirecting stderr to '/serverdata/Steam/logs/stderr.txt'
Looks like steam didn't shutdown cleanly, scheduling immediate update check
src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize.
Thread failed to initialize
[ 0%] Checking for available updates...
src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize.
Thread failed to initialize
--- -
2 hours ago, ich777 said:
What GAME_ID are you using so that I can try it on my own?
The default: 294420
In the past it's never been difficult. This time, I simply add the container and leave all the settings to the defaults for now (ports, etc.) and after "apply" is does some typical preparatory stuff then gets no further.
The initial report (this seems fine...):
---Pulling image: ich777/steamcmd:7dtd
IMAGE ID [7dtd]: Pulling from ich777/steamcmd.
IMAGE ID [3ac06a45bc97]: Pulling fs layer. Downloading 100% of 30 MB. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [5ecfdce331fd]: Pulling fs layer. Downloading 100% of 8 MB. Download complete. Extracting. Pull complete.
IMAGE ID [397e02e644be]: Pulling fs layer. Downloading 100% of 10 MB. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [bb5b24889a61]: Pulling fs layer. Downloading 100% of 2 KB. Verifying Checksum. Download complete. Extracting. Pull complete.
IMAGE ID [e8e52096371b]: Pulling fs layer. Downloading 100% of 2 KB. Download complete. Extracting. Pull complete.
IMAGE ID [7eff29bf6c41]: Pulling fs layer. Downloading 100% of 2 KB. Download complete. Extracting. Pull complete.
Status: Downloaded newer image for ich777/steamcmd:7dtd
TOTAL DATA PULLED: 48 MBCommand:root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='7DaysToDie' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'GAME_ID'='294420' -e 'SERVERCONFIG'='serverconfig.xml' -e 'GAME_PARAMS'='-logfile 7DaysToDie_Data/output_log.txt $@' -e 'VALIDATE'='' -e 'ENABLE_BEPINEX'='false' -e 'USERNAME'='' -e 'PASSWRD'='' -e 'UID'='99' -e 'GID'='100' -p '26900:26900/tcp' -p '26900:26900/udp' -p '26901:26901/udp' -p '26902:26902/udp' -p '26903:26903/udp' -p '8080:8080/tcp' -p '8082:8082/tcp' -p '27015:27015/udp' -v '/mnt/user/appdata/steamcmd':'/serverdata/steamcmd':'rw' -v '/mnt/disk1/appdata/7dtd':'/serverdata/serverfiles':'rw' --restart=unless-stopped 'ich777/steamcmd:7dtd'
16c6a90f226c6c7707dafddc3a4c460243c8215b620c48b6c80942997749b6ef
The command finished successfully!
--- -
The 7 Days To Die container seems to be buggered since the recent (major) Alpha 20 update.
Basically, with a vanilla set-up, it creates the root: \7dtd directory and two subdirectories: \Saves and \User, then it goes into an endless loop of failure message in the log:
---
---Prepare Server---
grep: /serverdata/serverfiles/serverconfig.xml: No such file or directory
---Creating SaveGameFolder config ---
sed: can't read /serverdata/serverfiles/serverconfig.xml: No such file or directory
---Savegame location found---
grep: /serverdata/serverfiles/serverconfig.xml: No such file or directory
---Creating UserDataFolder config ---
sed: can't read /serverdata/serverfiles/serverconfig.xml: No such file or directory
---UserDataFolder location found---
---Server ready---
---Start Server---
/opt/scripts/start-server.sh: line 169: /serverdata/serverfiles/7DaysToDieServer.x86_64: No such file or directory
---FYI, this is on UnRaid server and was working flawlessly, up until the A20 patch. Also, prior to re-trying it, I removed the container and completely deleted the original \7dtd directory. I didn't change the: \steamcmd directory since that is used by other containers, like Rust, Don't Starve and those are all working.
Thoughts?
-
4 hours ago, ich777 said:
Especially steam ports don't like it if you set the containerport to 27015 and the hostport to 27016 or something else, I run on my server for example 3 servers (not 7DtD) with the first container owning the port 27015 and the last one 27017 (this has to be done manually).
This is the part that's a bit strange to me... In your example, you set a container port to say 27016, but how does the game know to use that port unless it's specified somewhere? (I'm assuming the default is 27015) That's why I was asking about the "+1" idea with the serverconfig.xml; if you simply set the serverconfig to say 26905, does the game know to move-up the port numbering to find the rest of the ports used? Does the game "scan" though a range of ports? (seems unlikely...)
In any case, when I duplicate (but shift +5 to 26905) my -working- OMV ports, the Unraid-hosted server can be seen by the in-game browser, but you get a timeout trying to connect. Something is missing, but I don't know what!
FYI, switching to host mode works fine with the example attached (26905 and note the container ports shifted to match), but that's really not a "solution"!
What makes it more complicated is that you really need to test connectivity though a VPN since servers on your LAN will appear to work fine, with settings that will fail for external clients.
.thumb.jpg.448f173073b8dce850c749cee1f828f2.jpg)
-
13 minutes ago, ich777 said:
No, the config files for the game that are in the gameconfig folder in your appdata directory.
Click on the Docker Container and edit, that's the template.
Delete the existing one for example let's say 'UDP5 - Registering at server list' and create a new port with the containerport 27016 and hostport 27016 udp (instead of 27105).
But you are running Unraid or am I wrong? Because you mentioned OMV...
Ah, OK...
The only port I've ever seen in serverconfig.xml is a single instance of 26900. Are there other instances that need to be changed, or does it assume that's the base port and does +1, +2, etc. internally?
Check on the "delete and replace", vs. simply trying to update the template. The last entry (UDP5) warns about that and if you change the serverconfig.xml, it follows...
I'm just messing around with both platforms! OMV/Portainer works, but is a helluva lot more work to figure out and is sheer hell to try to get access to the /players directories! (Linux permissions are almost impassible and WinSCP is about the only option for file changes/additions) I just uploaded the Portainer image to show that a functioning server does not use 27015/16 in bridge mode.Thanks for the quick replies!
-
12 minutes ago, ich777 said:
You have to change all ports in your config to not overlap with the first container and then you have to delete all port mappings in the template and redo it with the same container and host ports.
Most gameservers doesn't like it when you just change the port in the template itself like container 27015 and host 27016 <- if you do it like this you can query the game but you will get a timeout since the game thinks it's on port 27015 and tries to connect throught that port but can't because it's actually 27016, hope this makes sense to you...
OK, to get the terminology straight, in your reply, the "config" you refer to is the list of port mappings under "Update Container"? (been there, done that...)
Where would you see/edit the "template" in Unraid? Also, I don't follow what "redo it" refers to...
(I had no overlaps since the mappings were all changed to 2790x, etc. and the other instance is running on a different box under OMV) Oh yeah, under OMV, I don't port-forward 27015/16 and it works fine! I suspect that 26900 TCP/UDP might actually be the only port needed!
Sorry if the questions seem obvious, but it seems like it should be simple, but there's a core issue I'm not addressing!
-
Question: 7 Days to Die and multiple container instances and/or other existing servers and Bridge mode?
More for curiosity and elegance, I'm trying to figure out how to make a 7DTD container that uses non-standard ports work in Bridge mode. I've got it to the point where an external user can connect via IP, bit the game is not advertised on the list. I can also get it to appear on the list, but it times-out trying to connect!
There's (maybe) some magical combination of ports & forwarding that will make it work, but I haven't figured it out yet!(FYI, Host mode works, but that's cheezy and overkill and can cause other issues...)
Also, I have a 7DTD server running on OMV/Portainer (didstopia/7dtd-server) with bridge mode and it works fine, albeit with the default ports.
) This time, I changed the game name and password ONLY!
.jpg.3a6784d5e6d3d99e932fc069a8cc166e.jpg)
[Support] Minecraft-Server
in Docker Containers
Posted
Two things (first should be easy!)
1) I change the Container Variable SEED to some number, but upon restart, the server is using exactly the same (empty) seed!
2) Is there an easy way to change some of the default settings in the server.properties file (like: online-mode=true) that are not exposed to the Unraid container update page?