Previously the logs for a single connection would be something like:
2016/05/04 12:44:41 171 Accepted connection on fd 5 from 00000002.00010006
2016/05/04 12:44:41 171 Connected to docker &{{0xc82008a5b0}}
2016/05/04 12:44:44 171 copying from vsock to docker: 4465 bytes done
2016/05/04 12:44:44 171 copying from docker to vsock: 1324 bytes done
2016/05/04 12:44:44 171 Done. read: 4465 written: 1324
2016/05/04 12:44:44 171 Closing docker &{{0xc82008a5b0}}
2016/05/04 12:44:44 171 Closing vsock &{0xc820086840}
The "Connected" and "Closing" lines are not useful now that it is debugged and
working well. The "copying..." lines are redundant with the "Done" line. Reduce
to just:
2016/05/04 14:00:41 4 Accepted connection on fd 10 from 00000002.00010003
2016/05/04 14:00:41 4 Done. read: 90 written: 145
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Using 23a432c2-537a-4291-bcb5-d62504644739 as the GUID (randomly generated).
The Windows host side will uses this as service ID, once written.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Otherwise the underlying gets closed twice, once by the File's finalizer (which
occurs at whichever point vsock appears no longer used) and another time by the
syscall.Close(), which leads to EBADF. The various syscall.shutdown can also
suffer from this if the File happens to get finalized first, but the reference
in the defer'd function now keeps the File alive until we are truly done with
the socket.
This seems to resolve the random stalls and failures seen in "make test".
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
