helm: ...\repositories.yaml: The process cannot access the file...

I am trying Helm 3 Beta 4 and am running into an issue when trying to add a repo. When I try the same thing with Beta 3 I do not get the error.

Command helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Result Error: read C:\Users\me\AppData\Roaming\helm\repositories.yaml: The process cannot access the file because another process has locked a portion of the file.

Output of helm version: version.BuildInfo{Version:“v3.0.0-beta.4”, GitCommit:“7ffc879f137bd3a69eea53349b01f05e3d1d2385”, GitTreeState:“dirty”, GoVersion:“go1.13.1”}

Output of kubectl version: Client Version: version.Info{Major:“1”, Minor:“14”, GitVersion:“v1.14.6”, GitCommit:“96fac5cd13a5dc064f7d9f4f23030a6aeface6cc”, GitTreeState:“clean”, BuildDate:“2019-08-19T11:13:49Z”, GoVersion:“go1.12.9”, Compiler:“gc”, Platform:“windows/amd64”} Server Version: version.Info{Major:“1”, Minor:“14”, GitVersion:“v1.14.6”, GitCommit:“96fac5cd13a5dc064f7d9f4f23030a6aeface6cc”, GitTreeState:“clean”, BuildDate:“2019-08-19T11:05:16Z”, GoVersion:“go1.12.9”, Compiler:“gc”, Platform:“linux/amd64”}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Docker for Windows

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 3
Comments: 26 (14 by maintainers)

Most upvoted comments

acquiring a lockfile instead of locking the repository file fixes the issue. It is indeed due to https://github.com/gofrs/flock/issues/42 as @hickeyma pointed out:

The second part is intentional. My goal when building the package was for building lockfiles separate from the data files it was operating on. So you use a common path to a lockfile, and then if you get that exclusive lock you can start working on the data files.

Will submit a PR.

PS C:\Users\me\code\go\src\helm.sh\helm> git diff .\cmd\
diff --git a/cmd/helm/repo_add.go b/cmd/helm/repo_add.go
index a28bb82a..bf65fd5e 100644
--- a/cmd/helm/repo_add.go
+++ b/cmd/helm/repo_add.go
@@ -85,8 +85,9 @@ func (o *repoAddOptions) run(out io.Writer) error {
                return err
        }

-       // Lock the repository file for concurrent goroutines or processes synchronization
-       fileLock := flock.New(o.repoFile)
+
+       // Acquire a lock on the repository file for concurrent goroutines or process synchronization
+       fileLock := flock.New(o.repoFile[0:len(o.repoFile)-len(filepath.Ext(o.repoFile))] + "lock")
        lockCtx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
        defer cancel()
        locked, err := fileLock.TryLockContext(lockCtx, time.Second)

bacongobbler on Oct 17, 2019

The fix is available in Helm 2.16.0-rc.1.

https://github.com/helm/helm/compare/v2.15.2...v2.16.0-rc.1

bacongobbler on Oct 30, 2019

Certainly.

bacongobbler on Oct 17, 2019

It was identified in https://github.com/helm/helm/issues/6770 that it was not released in 2.15.0 or 2.15.1. It will be in 2.15.2. Sorry about that!

For now, you may either build from source from the HEAD of the dev-v2 branch, or downgrade to 2.14.3. Either that or run Helm from a machine running an operating system other than Windows.

bacongobbler on Oct 24, 2019

Im trying to work around this issue by downgrading to helm v3.0.0-beta3. I have successfully added the stable repo with helm repo add stable https://kubernetes-charts.storage.googleapis.com/. The content of C:\Users\$USER\AppData\Roaming\helm\repositories.yml is now:

apiVersion: ""
generated: "0001-01-01T00:00:00Z"
repositories:
- caFile: ""
  certFile: ""
  keyFile: ""
  name: stable
  password: ""
  url: https://kubernetes-charts.storage.googleapis.com/
  username: ""

Switched back to v3.0.0-beta4 and the command helm repo list returns the configured repo. Now I can get back to learning Kubernetes & Helm. 🙂

riker09 on Oct 17, 2019