search

wolveix / satisfactory-server

A Dockerized version of the Satisfactory dedicated server
https://hub.docker.com/r/wolveix/satisfactory-server
MIT License
1.36k stars 150 forks source link

Azure Container Services - Failed to bind Socket 'FGServerAPISocket' To Address '0.0.0.0:7777': SE_EADDRINUSE #279

Closed CodeWarrior-Hawaii closed 1 month ago

CodeWarrior-Hawaii commented 1 month ago

Describe the Bug I have deployed to Azure Container services and the docker is up and running, but I am unable to connect. Immediately after a few lines in the log complaining about the "API is running using a Self-Signed Certificate", the error [2024.09.11-03.02.02:604][ 0]LogServer: Warning: Failed to bind Socket 'FGServerAPISocket' To Address '0.0.0.0:7777': SE_EADDRINUSE

Your Runtime Command or Docker Compose File Please see attached

I am using image b02914a46b1d1af6681cb9b0539e1af4fbddb4491b81a5a4a0110d8656c7e73e [2024.09.11-03.02.02:604][ 0]LogServer: Warning: Failed to bind Socket 'FGServerAPISocket' To Address '0.0.0.0:7777': SE_EADDRINUSE

Please see deployment yaml attached for deploy/run specs.

System Specs (please complete the following information): ===== START ISSUE REPORT ===== OS: Linux SandboxHost-638616203121414956 5.10.102.2-microsoft-standard #1 SMP Mon Mar 7 17:36:34 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux CPU: AMD EPYC 7763 64-Core Processor RAM: 11GB/11GB HDD: 296GB/50GB (1% used) ===== END ISSUE REPORT =====

Additional Context I attempted to find out what was using the port, but ss, netstat, and lsof were not available.

satisfactoryContainerDeploy.txt

log.txt

Edit: I have been unable to install ss, netstat, or lsof as it looks like the apt-get repositories are all disabled and the add-apt-repository command is missing. If I could find out what is using the port, THAT would be exceptionaly useful.

wolveix commented 1 month ago

Hey friend!

Nope, those are expected messages in the log. If you're unable to connect, you're using an old version of the container image. You need to upgrade.

wolveix commented 1 month ago

Please see #260 if you're confused/unsure, the top first post there should help!

CodeWarrior-Hawaii commented 1 month ago

Negative. Image hash that I am using is b02914a46b1d which is what is referenced in that post. I do not see any analog to networkmod = host for the yaml deploy that I am using. Will continue looking.

wolveix commented 1 month ago

@CodeWarrior-Hawaii could you confirm what you issue actually is? The cert being self-signed and the EADDRINUSE are both meaningless log messages (according to Coffee Stain themselves). You should be able to add the server in your server manager without any issues.

Oh I just looked at your deployment. Please re-read the README. You do not need 3 ports, you literally just need 7777/udp AND 7777/tcp. You must explicitly specify the protocols.

Additionally, you left your credentials in your deployment. You should change those immediately.

CodeWarrior-Hawaii commented 1 month ago

The Azure container deploy does not allow multiple instances of the same port in either of the sections specifying them, regardless of protocol. Protocol being an optional parameter should allow both TCP and UDP. I am waiting on an answer for a question in the Microsoft Azure Discord on whether that is in fact the case.

I will however remove the unnecessary ports from the deploy. They were there as a holdover from the previous incarnation of the deploy from when those ports WERE necessary (I think?).

CodeWarrior-Hawaii commented 1 month ago

Also, the specific issue is that in the server manager in-game, it reports that "This server appears to be offline." The error in the log regarding the port binding caught my eye being the only possible error of any importance that I could see, so I'd hoped that would be the problem. Port checking tools online show that 7777 is indeed open for the IP address that the container is running on. I would love it if I had some way of monitoring incoming traffic in the container instance, but it appears there is no tooling for that at the moment.

wolveix commented 1 month ago

@CodeWarrior-Hawaii when you checked that the port is accessible externally, did you check BOTH TCP and UDP? The server being offline usually means that UDP isn't open, while the API issues people were experiencing yesterday were due to TCP not being open

CodeWarrior-Hawaii commented 1 month ago

Hmm. I just used the ipvoid.com port scanner, it was the first one that I found that would do UDP specifically. The TCP scanner reported Open, UDP scanner reported Open|filtered. Not sure what that means yet.

Ah ok, so Open|filtered means there wasnt a reply, which for UDP makes sense. So is there an unequivocally negative return when the port is NOT open?

Also, those credentials are the sanitized version. I do not have a password that is MYACRPASSWORDHERE, nor is my account key "64bitencodedconnectionkey!!!", LOL. Just thought that would be funny.