-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Poor error when terraform init
fails to acquire a lock on the working directory's backend settings file on Windows (e.g. on a WSL share)
#35344
Comments
PS As a workaround, I have changed my workflow to call Terraform from WSL rather than from Linux. That works, but it's less comfortable because I cannot use my USB YubiKey as I normally do, for MFA. |
Hi @robpomeroy! Thanks for reporting this. Based on the trace log it appears that this behavior of running an external program using the Windows command interpreter belongs to the AWS SDK, which is being used indirectly by Terraform's S3 backend. I'm not deeply familiar with how the AWS SDK deals with credentials, but I do remember that it can be configured (e.g. in the AWS configuration in your home directory) to run an external program to gather the credentials. Do you think it's plausible that the AWS SDK might think it needs to run an external program to gather AWS credentials on your system, and that it's the launching of that program that's happening through the Windows command interpreter? |
I found the code in the AWS SDK that handles the task of executing an external process to gather credentials, and indeed it does seem to be hard-coded to use if runtime.GOOS == "windows" {
cmdArgs = []string{"cmd.exe", "/C"}
} else {
cmdArgs = []string{"sh", "-c"}
} I assume this is a compatibility constraint in that the command to run is an arbitrary string specified in the AWS configuration file and changing it to use PowerShell instead of the traditional Windows command interpreter would likely cause existing configured command lines to be interpreted differently than they are today. Regardless of the reason why it's written this way, this code is not directly part of Terraform and so I don't see any clear path to avoiding using |
That sounds plausible Martin. I have AWS calling aws-vault (and ykman for authentication and MFA. But this could be a red herring. I've been using Terraform/AWS/YubiKey successfully for years, but this is the first time I've run it from Windows on a plan that's inside WSL's filesystem. The If I just run |
Indeed, I think you're probably right that this error is a red herring. I expect that the AWS SDK is running Then downstream something else fails, unrelated to the launching of the credentials process, and so Terraform returns the "Error locking state" message. My next guess would be that Terraform is trying to do an I/O operation on the lock information file that the filesystem of the current working directory cannot support for some reason, and thus the Windows kernel is returning this "Incorrect function" error. I recognize "Incorrect function" as the English localization of a Windows error code that we've seen before in some other context, though I don't remember which one. |
Yes, that explanation fits well. 👍🏻 |
I think this is where that error message is originating: terraform/internal/command/clistate/state.go Lines 123 to 135 in 517f994
Behind the scenes, Terraform implements the locking for the file that contains the working directory's initialized backend settings (which is named terraform/internal/command/clistate/local_state_lock_windows.go Lines 28 to 45 in 517f994
I expect that whatever filesystem I assume from what appears in the path after it that Although I've not seen this particular symptom before, this sort of thing unfortunately commonly arises when crossing between Windows and Linux contexts, because the Windows version of Terraform is built to work with the Windows API and the Linux version of Terraform is built for the Linux API, and WSL often ends up supporting only the common subset of both out of necessity. Since you seem to be intending to work in a directory in your WSL environment anyway, could you instead using the Linux version of Terraform inside WSL, so that Terraform will expect the filesystem to behave in a Linux-like way rather than a Windows-like way? |
Although some of the fine details are different, this issue seems to confirm my hypothesis: microsoft/WSL#5762 |
The Go toolchain seems to have a similar problem for the same reasons, and I found a comment that mentions a workaround of diverting the directories needing locking to a different location. I don't have a Windows/WSL environment to test this on, but I think the Terraform equivalent of that workaround would be to set That approach does require some considerable care, though: Terraform expects that each working directory has a distinct "data dir", so if you set the |
Yes, running Terraform's Linux build within WSL is my workaround. I suspected this might be not worth fixing. Took me a while to figure out why Terraform was bombing out. Possibly the end user error message could be adjusted? |
Unfortunately "Incorrect function", aka However, I think there are some concrete opportunities to improve this code and the error message it returns:
|
terraform init
fails on Windows in a WSL UNC pathterraform init
fails to acquire a lock on the working directory's backend settings file on Windows (e.g. on a WSL share)
If microsoft/WSL#5762 is fixed at some point in a way that makes |
Terraform Version
Terraform Configuration Files
Not relevant.
Debug Output
https://gist.github.com/robpomeroy/96161fd561e6a109947b636fcd522567
Expected Behavior
Terraform initialises
Actual Behavior
When running
terraform init
from Windows on a WSL file path, this fails with an error:Running from PowerShell provides a little more insight, adding to the above:
It looks like
terraform init
invokesCMD.EXE
when run from PowerShell. AndCMD.EXE
can't handle changing to a UNC path so ends up in the wrong directory. InCMD.EXE
, presumably Terraform cannot correctly interpret the UNC path.Steps to Reproduce
/tmp/plan
or from Windows, e.g.\\wsl.localhost\AlmaLinux9\tmp\plan
).Set-Location \\wsl.localhost\AlmaLinux9\tmp\plan
)terraform init
Additional Context
In my development environment, I use a junction point to map
C:\Repos
(link) to\\wsl.localhost\AlmaLinux9\mnt\wsl\repos
(target). HenceCMD.EXE
allows me to enter the WSL directory usingcd C:\Repos
, i.e., without needing to use a UNC path. My system is set up for a lot of cross-platform work and I keep my repositories inside WSL for performance reasons (known issue with WSL2 file performance).Appears to be somewhat related to #29483, albeit in a different context.
References
No response
The text was updated successfully, but these errors were encountered: