sccache fails in bitbucket pipeline with "Connection refused (os error 111)"
Asked by michael.seele:

We start to use rust for backend development. To speed up compilation in our bitbucket pipelines, we want to use sccache (<https://github.com/mozilla/sccache>).

Locally, sccache works perfectly fine. Inside the bitbucket pipeline, sccache failes hard with a "Connection refused (os error 111)" (please see more under <https://github.com/mozilla/sccache/issues/1745>).

Is there anything known about a similar problem in bitbucket pipelines? This is really a pain point for us.


Answers:
author: michael.seele
body: [@Patrik S](/t5/user/viewprofilepage/user-id/4603309) commented with the correct answer. It seems to be a s3 permission problem.


author: Erez Maadani
body: Hi [@michael.seele](/t5/user/viewprofilepage/user-id/5216049)

Looks like there is an issue with opening your config file. The usual suspects are does the file actually exists at the time you call the parse command and does it have the correct permissions.

Also, do note that files and folders do not pass by default from one step to another, so if you didn't [cache](https://support.atlassian.com/bitbucket-cloud/docs/cache-dependencies/) the config file/folder explicitly, it won't be available in the next steps.

comments: author: michael.seele
body: Thanks for your answer. Unfortunately sccache works without config file. I have no config file locally, too.

So this might be not the issue. For me it looks like something with the internal network is broken in the pipeline step. The client cannot connect to the server on localhost port 4226.

Are there any restrictions in this direction? Is there anything how I can test the internal network in a bitbucket pipeline step?


author: Patrik S
body: Hello [@michael.seele](/t5/user/viewprofilepage/user-id/5216049) ,

I'm not really familiar with **sccache**, but I've tried to setup a simple pipeline to start the scchace server and check if it was listening on port 4226 using the following YML file :

```
image: rust:latest

pipelines:
  default:
      - step:
          script:
            - export SCCACHE_LOG=trace
            - cargo install sccache
            - sccache --start-server
            - sleep 15
            - sccache --show-stats
            - apt-get update
            - apt-get install net-tools
            - netstat -tulpn
```

The log output of the above pipeline indicates that the server was started, and the client was able to connect successfully when the command ***sccache --show-stats*** was executed. The last ***netstat*** command was to confirm that **sccache** server was still listening for requests on port 4226.

With that in mind, I see the difference in your configuration is that you are using the AWS s3-stored cache. In order to find out if some s3 setting is the culprit here, could you please try using the sccache option of **local** cache instead and see if you get the same error?

Thank you, [@michael.seele](/t5/user/viewprofilepage/user-id/5216049) !  
Patrik S


author: michael.seele
body: [@Patrik S](/t5/user/viewprofilepage/user-id/4603309) thanks for contacting me and the great reply.

It seems to be an s3 connection problem. By using a local cache, the pipeline is successful. That solves the pipeline problem and I need to look at the s3 permissions.

By the way, a better error message from sccache would have saved us hours. I will report this back to sccache.

Thank you.


Tags: bitbucket-cloud

bitbucket-pipelines

cloud