"spin deploy" failed due to port 5080 already occupied

luchfirearmland commented 2 months ago

Current Behavior

So the issue started when I tried to run "spin deploy" so I can deploy my changes. As you can see in the image below, the deploy process was halted because it can't establish an SSH tunnel.

At first I thought my SSH is not correctly configured and so I tried running this command: ssh -p 22 deploy@18.***.***.** I thought it wouldn't work but it did. Which means that I can do an SSH connection but port forwarding fails for some reason.

And so I tried to ask the error on Gemini. It told me that yes the SSH connection is indeed successful but it can't do the port forwarding because the port 5080 might be occupied by some process. I then followed the commands to check it out if indeed there's something running on that port, and it sure did!

I then proceeded to kill that process by its ID: sudo kill 377159.

Afterwards, I tried running spin deploy once again and it now works!

Expected Behavior

I expected spin deploy to run without fail. It failed due to port 5080 being occupied at the moment.

Steps To Reproduce

I actually don't know how it happened. But it might be because I abruptly stopped the already running spin deploy so it didn't finish closing the connection.

Environment

Spin Version: 
v2.0.1 [stable] (User Installed)

Operating System Version: 
ProductName:            macOS
ProductVersion:         14.6.1
BuildVersion:           23G93

Docker Info: 
Client:
 Version:    26.1.3
 Context:    orbstack
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.15.1
    Path:     /Users/jsluchavez/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.3
    Path:     /Users/jsluchavez/.docker/cli-plugins/docker-compose

Server:
 Containers: 41
  Running: 5
  Paused: 0
  Stopped: 36
 Images: 165
 Server Version: 26.1.4
 Storage Driver: overlay2
  Backing Filesystem: btrfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2bf793ef6dc9a18e00cb12efb64355c2c9d5eb41
 runc version: 58aa9203c123022138b22cf96540c284876a7910
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.9.8-orbstack-00170-g7b4100b7ced4
 Operating System: OrbStack
 OSType: linux
 Architecture: aarch64
 CPUs: 8
 Total Memory: 2.51GiB
 Name: orbstack
 ID: c205a1bd-58fe-4a98-bb2e-81cf8f906247
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine
 Default Address Pools:
   Base: 192.168.215.0/24, Size: 24
   Base: 192.168.228.0/24, Size: 24
   Base: 192.168.247.0/24, Size: 24
   Base: 192.168.207.0/24, Size: 24
   Base: 192.168.167.0/24, Size: 24
   Base: 192.168.107.0/24, Size: 24
   Base: 192.168.237.0/24, Size: 24
   Base: 192.168.148.0/24, Size: 24
   Base: 192.168.214.0/24, Size: 24
   Base: 192.168.165.0/24, Size: 24
   Base: 192.168.227.0/24, Size: 24
   Base: 192.168.181.0/24, Size: 24
   Base: 192.168.158.0/24, Size: 24
   Base: 192.168.117.0/24, Size: 24
   Base: 192.168.155.0/24, Size: 24
   Base: 192.168.147.0/24, Size: 24
   Base: 192.168.229.0/24, Size: 24
   Base: 192.168.183.0/24, Size: 24
   Base: 192.168.156.0/24, Size: 24
   Base: 192.168.97.0/24, Size: 24
   Base: 192.168.171.0/24, Size: 24
   Base: 192.168.186.0/24, Size: 24
   Base: 192.168.216.0/24, Size: 24
   Base: 192.168.242.0/24, Size: 24
   Base: 192.168.166.0/24, Size: 24
   Base: 192.168.239.0/24, Size: 24
   Base: 192.168.223.0/24, Size: 24
   Base: 192.168.164.0/24, Size: 24
   Base: 192.168.163.0/24, Size: 24
   Base: 192.168.172.0/24, Size: 24
   Base: 172.17.0.0/16, Size: 16
   Base: 172.18.0.0/16, Size: 16
   Base: 172.19.0.0/16, Size: 16
   Base: 172.20.0.0/14, Size: 16
   Base: 172.24.0.0/14, Size: 16
   Base: 172.28.0.0/14, Size: 16

Anything else?

No response

CodeWithKyrian commented 1 month ago

I'm having a similar problem here, but I can't see any running processes running on port 5080 to kill

YevheniiVolosiuk commented 1 month ago

Check also if you did not use some similar programs which can use a docker etc.

Like I have if I run my local WP tool and try to start laravel docker it will not work. After closing a program I can run a laravel docker etc.

CodeWithKyrian commented 1 month ago

After a few runs, I've noticed it usually happens when something unexpected makes the deploy fail besides the expected internal errors. For eg. network failure or SIGINT.

The script doesn't gracefully exit by cleaning up the docker registry and every other changes it made

jaydrogers commented 1 month ago

Strange... I have the cleanup set here:

https://github.com/serversideup/spin/blob/21f987e1ac88ef50e0c1528b444a729aa8527486/lib/actions/deploy.sh#L193

Which calls:

https://github.com/serversideup/spin/blob/21f987e1ac88ef50e0c1528b444a729aa8527486/lib/actions/deploy.sh#L105-L115

Is there any improvements you see here?

jaydrogers commented 1 month ago

I found the culprit. The tunnel_pid was not set until the end of the script. This could cause it to fail and never kill the tunnel.

I separated the tunnel and registry clean up and it should work a lot better.

I have this on this commit and it will be made available in the next release of Spin https://github.com/serversideup/spin/commit/7e20189d45c8ff13abdc14cd72ad4426c372f6aa

serversideup / spin