How to get the lock id?

[robsonpeixoto]

Terraform Version

$ terraform version
Terraform v0.11.3
+ provider.azurerm v1.2.0

I need to force a unlock, but how to get the lock id?

$ terraform destroy
Acquiring state lock. This may take a few moments...

Error: Error locking state: Error acquiring the state lock: 2 error(s) occurred:

* storage: service returned error: StatusCode=409, ErrorCode=LeaseAlreadyPresent, ErrorMessage=There is already a lease present.
RequestId:132435b7-101e-004b-552e-b732a8000000
Time:2018-03-08T22:41:18.7452012Z, RequestInitiated=Thu, 08 Mar 2018 22:41:18 GMT, RequestId=132435b7-101e-004b-552e-b732a8000000, API Version=2016-05-31, QueryParameterName=, QueryParameterValue=
* blob metadata "terraformlockid" was empty

Terraform acquires a state lock to protect the state from being written
by multiple users at the same time. Please resolve the issue above and try
again. For most commands, you can disable locking with the "-lock=false"
flag, but this is not recommended.

~> terraform force-unlock 132435b7-101e-004b-552e-b732a8000000
Do you really want to force-unlock?
  Terraform will remove the lock on the remote state.
  This will allow local Terraform commands to modify this state, even though it
  may be still be in use. Only 'yes' will be accepted to confirm.

  Enter a value: yes

Failed to unlock state: failed to retrieve lock info: blob metadata "terraformlockid" was empty

[jbardin]

Hi @robsonpeixoto,

Thanks for filing this. For most backends, the error message would indicate exactly what the lock ID was. In this case, the metadata blob is missing altogether, so terraform never gets to print the lock information. I believe, as you've guessed, that the lock ID is also the lease RequestID, but in your case the failure to fetch the lock info causes the unlock to abort before the lease can be released.

Unfortunately I'm not really familiar with azurerm, but there might be some method through the web console or cli to release the lease on the state blob itself.

@tombuildsstuff, do you what the easiest workaround for this might be, until I get a patch into the backend?

[tombuildsstuff]

hey @robsonpeixoto

So there's a workaround for this issue in this comment - but this can either be done using the Azure CLI or the Azure Blob Storage Explorer, by releasing the lock on the file.

There's a separate task to update the AzureRM Backend to workaround this issue which is being tracked in #17046.

[robsonpeixoto]

Thanks @tombuildsstuff.

[apparentlymart]

It sounds like the other discussions Tom linked have workarounds to get you what you need here in the short term, @robsonpeixoto, so I'm going to close this issue just to consolidate the discussion over in #17046.

Sorry for the weird behavior here, and thanks for reporting it!

[davehowell]

This is a true story! It happened to me a friend of a friend of mine.

I have a project that spans both AWS and GCP, the tfstate is stored on GCP in a cloud storage bucket (p.s. that is so much nicer than the AWS solution involving dynamoDB).

My environment requires temporary credentials & token for AWS. I've noticed that when I run terraform apply, if I don't currently hold valid AWS credentials, then it takes a reeeaaally long time to time out. A really long time. It's kind of my fault that it fails, because I forget to refresh my AWS credentials, but how long it takes to time-out is suuuper annoying. As a side note, is there anything I can do to make it fail faster? Probably a question for the AWS Provider side, anyhow.

My hokey-pokey jig is to cancel the terraform apply with control+C a couple times, then refresh my credentials and then terraform apply again. Previously I had the tfstate locally, and didn't see any lock issues, I guess there's no locking for local state- what would be the point of locking-for-one. With state now on GCP, it's failed to unlock.

It's probably the second time I hit control+C that is the cause of this problem; terraform is even kindly warning me that the first time it shuts down gracefully (but I am too impatient for that) and the second time just exits abruptly. It's the correct behaviour, P.E.B.K.A.C.

Move along nothing to see.

[einSelbst]

I had that same problem with AWS. Looking into the dynamo db table to see the ID there was working, but I guess when I'm there already I can also just delete the entry right there!?

[aryannava]

rename your terraform.tfstate file. Looks like it got corrupted
I got an alike problem and I renamed the file

Error: Error locking state: Error acquiring the state lock: open terraform.tfstate: permission denied

Terraform acquires a state lock to protect the state from being written

by multiple users at the same time. Please resolve the issue above and try

again. For most commands, you can disable locking with the "-lock=false"

flag, but this is not recommended.

aryan@aryan-VirtualBox:~/docker$ ls

main.tf terraform.tfstate

aryan@aryan-VirtualBox:~/docker$ ll

total 20

drwxr-xr-x 3 aryan aryan 4096 May 7 14:07 ./

drwxr-xr-x 21 aryan aryan 4096 May 7 13:57 ../

-rw-r--r-- 1 aryan aryan 279 May 7 13:57 main.tf

drwxr-xr-x 3 aryan aryan 4096 May 7 12:26 .terraform/

-rw-r--r-- 1 root root 1161 May 7 12:37 terraform.tfstate

aryan@aryan-VirtualBox:~/docker$ ls .terraform/

plugins

aryan@aryan-VirtualBox:~/docker$ less terraform.tfstate

aryan@aryan-VirtualBox:~/docker$ mv terraform.tfstate old_terraform.tfstate

[i255d]

I ran this from a command prompt in PowerShell and it unlocked my file: $ Get-Process terraform | Stop-Process -force

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.