Terraform: Failed to save state: truncate /dev/null: invalid argument

[jen20]

Terraform Version

Terraform v0.10.7

Terraform Configuration Files

resource "aws_s3_bucket" "state" {
    bucket = "some-name-that-isnt-taken-yet"
}

Expected Behavior

$ terraform apply -state=/dev/null -lock=false

Expected to discard state, as worked in Terraform 0.10.

Actual Behavior

Failed to save state: truncate /dev/null: invalid argument

Failed to persist state to backend.

The error shown above has prevented Terraform from writing the updated state
to the configured backend. To allow for recovery, the state has been written
to the file "errored.tfstate" in the current working directory.

Running "terraform apply" again at this point will create a forked state,
making it harder to recover.

To retry writing this state, use the following command:
    terraform state push errored.tfstate

Important Factoids

This is not a common operation, but is often used in bootstrapping new accounts - specifically for creating a bucket _for_ remote state. This problem only presents in somewhat recent versions (though I haven't bisected to find the regression).

[CumpsD]

Just hit this too on v0.11.1

[doertedev]

Confirming on Terraform v0.11.8 that this is stilla n issue, no matter if using -state or -state-out

[jonathortense]

This is happening to me when running terraform state rm -backup="/dev/null" .... via Jenkins.
It works well locally.

[apparentlymart]

Hi all!

This is a pretty old issue... sorry we didn't see it and respond to it sooner.

Terraform expects the local state file to be a normal file on a filesystem supporting features such as truncation and locking. While operating against a device node may have worked in the past, that is not a design goal and we don't intend to add further complexity to the local backend to make it work with device nodes that don't support normal file operations like truncation.

Instead, if you wish to simply throw the state away after creation, I'd suggest to specify a path in some temporary directory -- possibly on an in-memory-only file system -- and then delete the file when you're done.

If bootstrapping infrastructure for remote state storage is your use-case, I'd recommend a different path:

• Temporarily disable any existing remote backend configuration in the configuration, e.g. by commenting it out.
• Run terraform init to prepare the working directory to work with the local backend.
• Run terraform apply to create the necessary objects against a local terraform.tfstate file.
• Add or re-add the remote backend configuration.
• Run terraform init again, at which point it will offer to migrate the local state to the new remote backend, which should work now that the necessary infrastructure has been created.

This approach allows you to actually retain the state created during bootstrapping and do ongoing ongoing updates via the remote backend as long as you are careful not to destroy the infrastructure that the backend relies on, as opposed to discarding the state altogether immediately after creation.

Since storing state in device nodes is not something we intend to support, I'm going to close this out. Sorry we didn't see and respond to this sooner.

[hashibot[bot]]

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.