govmomi: investigating an error when `import.ova` occurs

We have a job that runs a govc import.ova periodically. We are experiencing a bug (20%) with the upload.

$ govc import.ova -options=/tmp/options.json737929222 image/ops-manager-vsphere-2.9.1-build.121.ova

[06-05-20 11:44:53] Uploading pivotal-ops-manager-disk1.vmdk... OK
panic: send on closed channel

goroutine 28 [running]:
github.com/vmware/govmomi/vim25/progress.(*reader).Read(0xc0003f6680, 0xc00054c000, 0x2000, 0x2000, 0xc0001b9b18, 0x408b9b, 0xc00001e000)
	/home/vmware/src/github.com/vmware/govmomi/vim25/progress/reader.go:116 +0x24c
io/ioutil.devNull.ReadFrom(0x0, 0x1431220, 0xc0003f6680, 0x101e7a0, 0x203001, 0x7f7e9e5de940)
	/home/dougm/golang-go/src/io/ioutil/ioutil.go:147 +0x92
io.copyBuffer(0x1433300, 0x1e86af8, 0x1431220, 0xc0003f6680, 0x0, 0x0, 0x0, 0x158946800, 0x0, 0x0)
	/home/dougm/golang-go/src/io/io.go:388 +0x2ed
io.Copy(...)
	/home/dougm/golang-go/src/io/io.go:364
net/http.(*transferWriter).doBodyCopy(0xc000096f00, 0x1433300, 0x1e86af8, 0x1431220, 0xc0003f6680, 0x158946800, 0x0, 0x0)
	/home/dougm/golang-go/src/net/http/transfer.go:400 +0x6a
net/http.(*transferWriter).writeBody(0xc000096f00, 0x142d940, 0xc00040b700, 0x2, 0x2)
	/home/dougm/golang-go/src/net/http/transfer.go:364 +0x733
net/http.(*Request).write(0xc0002d0e00, 0x142d940, 0xc00040b700, 0x0, 0xc00049a9f0, 0x0, 0x0, 0x0)
	/home/dougm/golang-go/src/net/http/request.go:682 +0x6d3
net/http.(*persistConn).writeLoop(0xc00009fd40)
	/home/dougm/golang-go/src/net/http/transport.go:2207 +0x1c8
created by net/http.(*Transport).dialConn
	/home/dougm/golang-go/src/net/http/transport.go:1575 +0xb23

The upload is successful, the import.ova is complete. I’m trying to capture this for SEO and to start our investigation.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 17 (6 by maintainers)

Most upvoted comments

We are going to add the environment variable GOTRACEBACK=all to our CI job. It routinely comes up every day or two, so it should be easier to reproduced.

As for a possible fix, without understanding what’s going on, is to wrap the channel write operation in an if statement to ensure the channel can be written to before attempting.

I’d like to figure out, though, why a channel is being written when the system implied it is Done.

jtarchie on May 6, 2020