This message was deleted.
# rancher-desktop
a
This message was deleted.
πŸ™Œ 1
a
thank you, will try this out
f
I kind of doubt this is related. If you don't have permission, it would prevent you to bind to the ports right away, and not close them after an hour.
Does the machine go to sleep before the ports are closed? Do you have some security software installed that might close them based on some idle detection (although I'm not sure how that would even work)
And have you tested if the ports still work locally? To determine if the shutoff is not imposed by e.g. an external firewall?
a
@fast-garage-66093 no security software, no anti-virus, no firewall. the machine doesn't go to sleep, I may be coding right on it, I also looked into App Nap.
f
Like, can you still connect via
localhost:80
even when the external IP doesn't work anymore?
It sounds really weird; I never heard of this happening
a
Yes, both locally and remotely 80/443 (or any port under 3000) is disabled. Accessing NodePort based pods (i.e. 30854, 8900, etc) works without a problem.
It happens on my MBP (Sequoia) and an older MacPro (Monterey).
f
This doesn't really apply. As I said, you would be blocked immediately if you didn't have permission to bind to the ports.
a
It's Linux focused but I'm going to give it a shot.
f
On macOS you can actually bind to
0.0.0.0:80
etc. without being
root
. Which is kind of weird because you need to be root to bind to
127.0.0.1:80
. But anyways, permission issues would prevent you from binding in the first place.
The only thing I can recommend is to enable "Debug" logging (on the "Troubleshooting" page), and then collecting all the logs if/when this happens again, and check them for any hints (or create a GitHub issue and upload them, if you are comfortable doing this (it will include your IP addresses, and image names).
a
I'm comfortable with that, I'm in a local network with a local IP (192.168).
I'm trying something now where I'm setting up nginx as a proxy (outside of Docker/RD) and forwarding to a higher port, since those don't close up.
f
Even if you figure out a workaround, please send an update here, as I'm curious to understand what is going on.
πŸ‘ 1
Maybe also check to see which app is listening on port 80, both before the port is blocked and after
Copy code
$ sudo lsof -i -P | grep :80
ssh       29679            jan   49u  IPv4 0x6066f8acb19edf91      0t0    TCP *:80 (LISTEN)
While they are forwarded by Rancher Desktop they should be bound to
ssh
, which is used for the port forwarding. So it would be curious to see if the port is bound to a different app at that time, or just unbound etc.
a
Will try that in a moment. I shutdown RD, lsof came back empty, then I installed nginx using homebrew, started it and it was running. I accessed from another machine and all good. I'm going to let it run for about an hour and will check again. This may be an OS thing?
@fast-garage-66093 the ssh user is because of the port forward to the VM that hosts RD?
f
Yes, but it is not a user name, it is a process name. This is an ssh tunnel
πŸ‘ 1
a
The standalone NGINX was still working this morning. So I cleaned out my RD and started over. Outside of Traefik, k3s, etc. there's no other containers. RD has admin access. I can see it remotely. Will leave it there for some time and hope to still access it.
Current lsof:
OK, two hours later Traefik is still responding ... maybe it was my prior setup? πŸ˜… I'm going to install a few deployments and see if this win streak continues.
So everything is still working as expected. I'll chalk it up to user error and a bad install for now. Thanks for your help @fast-garage-66093!
πŸ‘ 1