There may be times when you see error messages that read something like this:
rserver-monitor: ERROR system error 111 (Connection refused); OCCURRED AT void rstudio::core::http::TcpIpAsyncConnector::handleConnect(const rstudio_boost::system::error_code
Generally, this type of error message indicates a connection timeout, which more often than not, is the result of a firewall blocking access somewhere along the transmission path.
Whilst there may be any number of causes to this issue, there is a checklist of questions that can be asked which will help narrow down the issue. This can be broken down into three subsections - simple server setups, high availability setups, and connections to resource managers like Kubernetes or Slurm.
This type of server setup doesn't involve any additional servers to make RStudio Workbench run. It's constituted by a single RStudio Workbench server that communicates out to the internet, and maybe out to an RStudio Connect server. If you see connection refused errors, we would suggest checking:
- Does your RStudio Workbench server have internet access? You can test against the Google public DNS from the terminal by running ping 220.127.116.11.
- Does your RStudio Workbench server have the appropriate firewall rules to allow internet traffic to be passed back to Workbench?
- If unable to publish, does the firewall on your RStudio Connect server permit your RStudio Workbench instance to access it via its inbound firewall rules?
- If unable to publish to RStudio Connect, does its firewall have inbound access allowed for the RStudio Workbench server?
- Also for publishing, does your RStudio Workbench server permit your RStudio Connect instance to access it via its inbound firewall rules?
High Availability setups
This type of server setup uses a load balancer with multiple RStudio Workbench instances and an external database for greater fault tolerance. If you see connection refused errors, we would suggest checking the single server access as per above, and also asking the following questions:
- Does your RStudio Workbench instance have access to the external database via the database server's inbound firewall rules?
- Does your external database have access to your RStudio Workbench instance via its inbound firewall rules?
- Do each of the Workbench instances that sit behind the load balancer have the appropriate access via their firewall rules to pass traffic through the load balancer?
- Does your load balancer configuration permit traffic from the internet to be passed through it, and sent to your RStudio instances?
- Do your Workbench instances have access to an NFS share and can they read and write to the NFS server?
- Does your NFS share have the appropriate firewall rules to access your Workbench instances?
This type of server setup uses a resource manager (such as Kubernetes or Slurm) to launch containers that run your RStudio Workbench instance. Resource managers can be part of a high availability setup, or they can exist on their own. This section assumes that your resource manager work standalone. If you use a resource manager with high availability, we would suggest reviewing high availability setups before this section. Ask the following questions:
- Does your RStudio Workbench instance have access to your resource manager cluster via its inbound firewall rules?
- Does your resource manager cluster have access to RStudio Workbench via its inbound firewall rules?
- Does your resource manager cluster have access to your NFS share?
- Does your NFS share have access to your resource manager cluster?
- Are you able to manually launch new pods into your resource manager cluster via the command line in your RStudio Workbench instance?
If you still have issues after completing the above, you can always lodge a support ticket, where our group of friendly, and incredibly knowledgeable staff can assist with any issues that you may be having. You can submit a ticket here: