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

michael.seele May 10, 2023

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.

2 answers

1 accepted

0 votes
Answer accepted
michael.seele May 12, 2023

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

0 votes
Erez Maadani
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 10, 2023

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 May 10, 2023

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 11, 2023

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

Like michael.seele likes this
michael.seele May 12, 2023

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

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events