shell access on our application (hosted in Frankfurt) is very unreliable.
Very often we can not access it, the page seems to auto-refresh before we got any prompt (I can see a websocket error in the console wss://frankfurt-proxy.render.com/srv-c5680upg7hp0afmtbldg/shell)
This problem isn’t new and is very frequent, what do you suggest?
I’m sorry to hear about your issues with the shell- we’ll be looking further into this. To help with our investigation, I have a few questions:
Does this happen consistently? For example, if you go to the shell right now, is it it working? Does it still keep working if you refresh several times?
What browser do you use when you notice these issues?
Do these issues seem to happen more around the time when you’re deploying your service?
Do you notice this on other services, or just one?
The error happens randomly. But when it happens, it seems that no page refresh can fix the issue. Only redeploying the app seems to make the shell working again
Thanks for the extra information. The next time you run into this issue, could you post here again before redeploying your app so that we can take a closer look at the service and diagnose things? I’m unable to replicate the issue currently, but would like to take a closer look to find what the underlying problem might be.
Hi Christian - thanks for reporting this, keeping your service in this state has been very helpful for debugging.
It looks like whenever you get a Server Unhealthy event in your dashboard, your service recovers but is then in a state where the shell can’t operate correctly. It also looks like this might be connected to some CPU spikes.
From digging on our end, it looks like your service is maxing out the /tmp directory. Is your service writing a large amount of ephemeral data to /tmp? Especially during times when you get Server Unhealthy messaging, I suggest taking a look and seeing if there’s an unusual amount of writing to /tmp.
My other suspicion is that your service’s amount of log lines may be what is filling up /tmp.
Hope this helps with debugging - redeploying your service when it’s in this state should restore your shell access, but if we can prevent /tmp from becoming too full this shouldn’t be necessary in the first place.