sccache fails in bitbucket pipeline with "Connection refused (os error 111)"

[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.

[michael.seele · Accepted solution]

@Patrik S commented with the correct answer. It seems to be a s3 permission problem.

[Erez Maadani]

Hi @michael.seele 

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 the config file/folder explicitly, it won't be available in the next steps. 

[michael.seele]

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?

[Patrik S]

Hello @michael.seele ,

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 !
Patrik S

[michael.seele]

@Patrik S 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.