Error 500, port is already allocated

Hi,

We have several Shiny apps deployed with Shinyproxy, which works great. However, from time to time all apps stop working with the attached error. shinyproxy_error

We don’t know why all apps try to open on the same port in this case. The solution we found is to restart shinyproxy.

The docker settings in the application.yml are:
docker:
cert-path: /home/none
url: http://localhost:2375
host: 127.0.0.1
port-range-start: 40000

I would say that this happens, on average, once or twice a month.

Would you have an idea why this strange behaviour?

Thank you,
Andrei

Hi @ahalasz,

If this is happening, ShinyProxy assumes port 40007 is available, but it’s not.
This could either be another application allocating the port, or a previous proxy not shutting down correctly.

If it happens again, you can try a docker ps or a netstat -tln to find out who is using the port.

Hi,

Thank you for your quick answer. I just had again the same behaviour, saying that port 40007 is already allocated. The docker ps command is showing that no container is using that port (see attached). docker_ps

However, the netstat -tln command is showing that something is listening on port 40007 but I don’t know what.

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:40000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:40001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:40002 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:40003 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:40004 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:40005 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:40006 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:40007 0.0.0.0:* LISTEN

Further investigation suggested that an exited Docker container is still using port 40007. What is interesting is that is seems to always be port 40007 that is causing the issue.

Hi,

we are experiencing similar issue, sometimes we get Bind for 0.0.0.0:\(.*\) failed: port is already allocated. errors but we cannot reproduce it on demand. Killing the container which somehow did not shut down correctly solves the issue but requires manual intervention. Even automating killing these containers is not very user friendly: on the first try they get an error.

Do you know what is the root cause for this behavior?

regards,
Ildi