With no config changes, Retool 2.121.2 gives the following error:
Emitted 'error' event on Server instance at:
{
errno: -98,
code: 'EADDRINUSE',
syscall: 'bind',
address: null,
port: 3000
}
2.119.13 works fine. I have switched between both docker images a few times now just to check.
Any ideas?
Bump. We'd love to try the new table but can't since I can't get 2.121.2 working. Thanks
Hey @jimhuds!
The EADDRINUSE error suggests that something is already running on port 3000. Can you check if that's the case?
If you could share how you have Retool deployed and the exact steps you took to upgrade that would be great as well for additional context!
Hey @Kabirdas ,
There are some other things running on port 3000, but it's all managed by Traefik. We have quite a lot of other services running on the same server, so nothing is exposed directly.
Did something change in the docker image? Currently running 2.119.13 completely fine.
Might be worth noting that this error occurs no matter what I set PORT to in .env.
Cheers,
Jim
This is the full error:
Starting static http server on port 3000
{"address":null,"code":"EADDRINUSE","errno":-98,"level":"error","message":"There was an uncaught error bind EADDRINUSE null:3000","port":3000,"stack":"Error: bind EADDRINUSE null:3000\n at listenOnPrimaryHandle (node:net:1397:18)\n at rr (node:internal/cluster/child:155:12)\n at Worker.<anonymous> (node:internal/cluster/child:109:7)\n at process.onInternalMessage (node:internal/cluster/utils:49:5)\n at process.emit (node:events:538:35)\n at processEmit [as emit] (/snapshot/retool_development/node_modules/signal-exit/index.js:199:34)\n at emit (node:internal/child_process:938:14)\n at processTicksAndRejections (node:internal/process/task_queues:84:21)","syscall":"bind","timestamp":"2023-06-09T20:02:54.662Z"}
node:events:504
throw er; // Unhandled 'error' event
^
Error: bind EADDRINUSE null:3000
at listenOnPrimaryHandle (node:net:1397:18)
at rr (node:internal/cluster/child:155:12)
at Worker.<anonymous> (node:internal/cluster/child:109:7)
at process.onInternalMessage (node:internal/cluster/utils:49:5)
at process.emit (node:events:538:35)
at processEmit [as emit] (/snapshot/retool_development/node_modules/signal-exit/index.js:199:34)
at emit (node:internal/child_process:938:14)
at processTicksAndRejections (node:internal/process/task_queues:84:21)
Emitted 'error' event on Server instance at:
{
errno: -98,
code: 'EADDRINUSE',
syscall: 'bind',
address: null,
port: 3000
}
I noticed that its saying that it's trying to bind to null:3000, could this be the issue?
Thanks
have you been able to upgrade successfully before? Would you mind sharing more about the steps you took to upgrade as well?
Additionally, I'm wondering how the port mapping is set up in your docker-compose.yml file, and I'm not very familiar with Traefik but am also curious to know more about how you've set up port mapping in it.
Having null:port looks to actually pretty be common in EADDRINUSE errors when a port is already in use. Is Traefik managing server requests to port 3000 and routing them to different ports on various machines? Could you check if port 3000 is already in use on the machine where Retool is hosted?
It might also help to hear more about the service you're using to deploy Retool!
Yeah I've upgraded fine quite a few times.
Since we host a lot of things, I'm using Easypanel so that I can manage it easier, hosted on a Vultr VPS. I split out the docker-compose into separate 'services': main, db connector, jobs runner, ssh connector, postgres x 2 (db and retooldb). Pretty much everything is identical except I didn't add all of the mounts (only the SSH one).
I believe Easypanel itself is running on port 3000 of the VPS. But there are other services that run on port 3000 of their container, and I think Traefik routes incoming traffic to the container based on the exposed port and domain set. A lot of our other services share the same exposed port and do not clash. In Easypanel, there is a different setting to bind a port to the host machine, but I don't use it.
Since the other versions worked fine, I assumed there was some sort of change that makes retool bind to the host machine port by default instead of the container port, but I'm not sure.
To upgrade, I just change the version of the docker-hub image for each service and re-deploy (the same as doing docker-compose pull && docker-compose up).
Perhaps it would be worth booking a call or something to sort this out? It would be great to get it working as we have plans to use the new table for some stuff. In the meantime, would it be possible to enable the feature flag for us so that we can use it on 2.119.13?
Cheers!
Hey there! Just want to follow up here. The dev team has been looking into this and the behavior should be fixed in 2.121.9.
Let me know if you still run into the same issue when upgrading to that version, and thanks for surfacing this and providing the context that you did @jimhuds!