Update Failure with Application Deployment - After update to 2.6.0.6, docker instances fail to bind ports

System Information

Field Value
Operating System Windows - Windows 11 Pro on x86_64
Product AMPService ‘Phobos’ v2.6.0.6 (Mainline)
Virtualization None
Application Application Deployment
Module ADSModule
Running in Container No
Current State Indeterminate

Problem Description

Issue

I had three instances running under AMP version 2.6.0.4 using docker containers on a win11 x64 pc. After upgrading to 2.6.0.6, all instances fail to start or upgrad outputting that docker fails to bind the webserver port as its already in use. The same applies for creating a new instance.
Steps to resolve the issue so far:

  • checked via taskmanager, resourcemanager and netstat → port is not in use
  • checked docker, if any container was running → no container running
  • tried to run docker as admin to check for permission problems → no change
  • reset docker to factory settings → AMP downloads the image again, then fails again.
  • tried to restore backup instance config files → nothing changes
  • tried to change the webserver port → fails as the instance wont start
  • looking at the discord and discourse, there seem to be some people having these issues, but nothing on there worked so far

Reproduction Steps

  • Have a running 2.6.0.4 installation with docker instances
  • stop all instances via ampinstmgr
  • install version 2.6.0.6 on win11
  • after installation finishes, run installer again and repair
  • upgrade ads via ampistmgr
  • reboot system
  • all instances fail to upgrade or start as they think the required webserver port is already in use eventhough it is not

Make sure that your ampinstmgr CLI tools are up to date.
(if you run ampinstmgr version in CMD it should print out v2.6.0.6)
https://discourse.cubecoders.com/t/how-to-update-amp-to-the-latest-version/2297

1 Like

Thanks for your reply, I have checked it and it returns 2.6.0.6. ampinstgmr list shows verison 2.6.0.6 for all instances as well

At any point did you run ampinstmgr repair? (because that can cause some funky issues)

Not as far as I remember, I ran into some troubles when updating to 2.6.X for the first time, but eventually got it all sorted out. I don’t know if I have used it back then, but definitely not after the last two updates.

Run ampinstmgr lastlog ADS01 to check what port the ADS is trying to bind to, in case it’s different from the readout in ampinstmgr

Both urls seem to fit as far as I can see it…
I copied the part from the log and the output from ampinstmgr list below (probably should have done that earlier…). It’s from right after the update, the current output is the same, though:

log:

[13:42:47] [ADS:XXX Activity/23] : Upgrading instance Satisfactory_Vanilly01
[13:42:53] [InstanceManager:XXX Info/19] : Using default tag: latest
[13:42:54] [InstanceManager:XXX Info/19] : latest: Pulling from cubecoders/ampbase
[13:42:54] [InstanceManager:XXX Info/19] : Digest: sha256:a18b6bc46f5622ff7572400b6ed3c3630aed4d26326a919873dd83265463e161
[13:42:54] [InstanceManager:XXX Info/19] : Status: Image is up to date for cubecoders/ampbase:latest
[13:42:54] [InstanceManager:XXX Info/19] : docker. io/cubecoders/ampbase:latest
[13:42:54] [InstanceManager:XXX Info/19] : beca7a85d799e3f5daf16d61ea91f08fd527ef77a104837130c96938f468649f
[13:42:55] [InstanceManager:XXX Info/23] : docker: Error response from daemon: driver failed programming external connectivity on endpoint AMP_Satisfactory_Vanilly01_CONFIGURE (c62e56d7a3189f3c5064010a8839a297a323c8202f79eb14f170f368fe0530a0): failed to bind port 0.0.0.0:8084/tcp: listen tcp4 0.0.0.0:8084: bind: address already in use.
[13:42:55] [InstanceManager:XXX Warning/27] : Failed to configure new instance Satisfactory_Vanilly01 - Startup failure: Docker returned error code 125#

ampisntmgr:

Instance ID │ 42e9e1e4-3cbf-4862-b1d6-76aa056196ff
Module │ GenericModule
Instance Name │ Satisfactory_Vanilly01
Friendly Name │ Satisfactory_Vanilla
URL │ http:// 127.0.0. 1:8084/
Running │ No
Service Instance │ No
AMP Version │ 2.6.0.6
Release Stream │ Mainline
Data Path │ C:\AMPDatastore\XXX

I also tried running a docker container on the same port for testing purposes, that worked without any problems (the container existed only for the test, did not run when the instance should have been started and was deleted right after the test)

Looks like your ADS is trying to bind to 8084
What’s the output of ampinstmgr status?

The output for the instance looks like this:

←]8;;http:// 127.0.0. 1:8084/Satisfactory_Va…←]8;; │ Satisfactory_… │ Generic │ 0.0.0.0 │ 8084 │

No other instance uses 8084.
thanks for taking the time!

What’s the full output? Does it say 8080 for the ADS?

Yes, it’s running on 8080. i copied the entry for ADS below, in between are two more instances (8081 and 8082) which I setup outside of docker as a workaround to get them running again.

←]8;;http:// 127.0.0. 1:8080/ADS01 ←]8;; │ ADS │ ADS │ 0.0.0.0 │ 8080 │ V
←]8;;http:// 127.0.0. 1:8084/Satisfactory_Va…←]8;; │ Satisfactory_… │ Generic │ 0.0.0.0 │ 8084 │

Actually, I think I found the problem. When setting the loglevel to debug, it shows that it AMP tries to run docker with the the following port settings for satisfactory

-p 8084:8084/tcp -p 2227:2227/tcp -p 7778:7778/tcp -p 7778:7778/udp -p 8084:8084/tcp

for some reason, the webserver port is mentioned to times in the command.
In the AMPConfig of the instance and the instances.json file, this port is only mentioned once per file and whats especially curious to me is that the same error was thrown when creating a new instance. Does anyone have an idea where this command may come from?

Looks like there’s a discrepancy in the ADS’s log vs the status output.
Run ampinstmgr rebind ADS01 0.0.0.0 8080 in CMD.
Ignore the part about fixing auth, as we’re running the command to restore things to their defaults

Unfortunately, the problem still stays the same. When trying to create a new instance, AMP still tries to bind the webserver port twice via the docker run command.
The only thing that changed was some more errors, probably due to a now outdated configuration of the instances:

LIM - Failure to make API call to Satisfactory_Local01: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte. (127.0.0.1:8081)
Translated to english it means “A connection could not be established, because the remote computer refused the connection.”

Yeah, you might have to run the ampinstmgr rebind command for the other instance to make sure that the status readout matches the existing instance.
You could try:
ampinstmgr rebind Satisfactory_Local01 0.0.0.0 8084
Because I bet that if you were to look at the log, it would somehow be 8081, confusing the new instance.
I could be wrong however, just my best guess

Sorry, that was my mistake, I have actually two satisfactory instances right now, satisfactory_local(on 8081) is a non-docker instance I have created after I could not get docker to work, so there was still a server online.
Satisfactory_Vanilly (on 8084) is a docker instance from before the update, so I still have one docker instance for testing purposes.
Sorry for the confusion…

Ah okay, maybe as a sanity check, look at Satisfactory_Vanilly’s latest log to see if it’s still bound to 8084.
If that looks fine, we can check Satisfactory_Local01’s logs to see if there’s anything strange with it starting up it’s web server

The latest log from Vanilly is still from before the upgrade to 2.6.0.6, as since then it was never able to start up. But all config files mention 8084.
The non-docker instance has only one entry in the LastLog regarding the webserver, which is

[00:43:18] [Webserver Info/1] : Webserver started on http:// 0.0.0.0:8081
All other entries are from SteamCMD or the Satisfactory Server.

What happens if you try to start Vanilly? Since we’ve fixed up the ADS’s port, it should be able to bind properly again (at least hopefully)

Unfortunately not, AMP still tries to run docker with two times the webserverport in the docker run command.
below is an example output from the logfile when creating a new docker instance.

Arguments: -firststart +Core.Webserver.Port “8083” +Core.Webserver.IPBinding “0.0.0.0” +Core.AMP.AppModule “GenericModule” +Core.AMP.InstanceID “446fb69e-426a-4bfb-9d4c-82b388fdac50” +Core.AMP.InstanceName “TS3_docker01” +Core.AMP.FriendlyName “TS3_docker” +Core.AMP.PrimaryEndpoint “0.0.0.0:9988” +Core.AMP.PrimaryEndpointUri “steam://connect/0.0.0.0:9988” +Core.Security.MetricsHMAKKey “XXX” +Core.AMP.LicenceKey “YYY”
Running AMP with configuration arguments…
Running command line: “C:\Program Files\Docker\Docker\resources\bin\docker.exe run --rm -id --name AMP_TS3_docker01_CONFIGURE -v “C:\AMPDatastore\Instances\TS3_docker01”:/AMP -v “C:\AMPDatastore\Instances\TS3_docker01.virtualhome”:/home/amp -e AMPUSERID=1001 -e AMPGROUPID=1001 -e AMPHOSTPLATFORM=Windows -e AMP_CONTAINER=1 -e AMP_MOUNTPOINTS=”" --mac-address XX:XX:XX:XX:XX:XX -p 8083:8083/tcp -p 2226:2226/tcp -p 9988:9988/udp -p 30034:30034/tcp -p 10012:10012/tcp -p 10023:10023/tcp -p 10081:10081/tcp -p 10444:10444/tcp -p 8083:8083/tcp cubecoders/ampbase -firststart +Core.Webserver.Port "8083" +Core.Webserver.IPBinding "0.0.0.0" +Core.AMP.AppModule "GenericModule" +Core.AMP.InstanceID "446fb69e-426a-4bfb-9d4c-82b388fdac50" +Core.AMP.InstanceName "TS3_docker01" +Core.AMP.FriendlyName "TS3_docker" +Core.AMP.PrimaryEndpoint "0.0.0.0:9988" +Core.AMP.PrimaryEndpointUri "steam://connect/0.0.0.0:9988" +Core.Security.MetricsHMAKKey "XXX" +Core.AMP.LicenceKey "YYY" -loadconfig provisionargs.kvp" from “”
38daa4923f2d81e88c08870ef134bea68be7151f5993f87199468cc249ba6bfb

16:50:03
docker: Error response from daemon: driver failed programming external connectivity on endpoint AMP_TS3_docker01_CONFIGURE (b3e45addf9b07792168f92f0c9adb0ffd644063b7a5d002f2fc7f4cf9e5cfed1): failed to bind port 0.0.0.0:8083/tcp: listen tcp4 0.0.0.0:8083: bind: address already in use.

As far as i see it, the problem is that docker is run with -p webserver-port:webserver -port some-other-ports webserver-port:webserver-port, which makes docker try to bind the same port twice which obviously fails.

Oh derp, I completely overlooked that in your previous message, my bad.
I’ll poke around and see if I can turn up anything