- don't try to create a `FileConn` because the Go library sees through
the scam and rejects it
- explicitly keep a reference to the `ctl` file just in case the GC
decides its dead and should be closed.
Signed-off-by: David Scott <dave.scott@docker.com>
The port will be automatically removed when the fd/fid is closed by
a process exit/crash, or by a hypervisor crash.
Signed-off-by: David Scott <dave.scott@docker.com>
The `NewProxy` function already knows how to deal with `net.UDPAddr`
and `net.TCPAddr`, this patch adds similar support for `vsock.VsockAddr`.
Signed-off-by: David Scott <dave.scott@docker.com>
This patch adds a wrapper around the `net.Conn` to include the
`CloseRead` and `CloseWrite` implementations. This patch also
exposes the `VsockAddr` type, which is similar to `TCPAddr` and
`UDPAddr`.
Signed-off-by: David Scott <dave.scott@docker.com>
We require the frontend to be a `net.Listener` and the `net.Conn`
connection which are established must be type-switched to
`Conn` to support the `CloseRead` and `CloseWrite` methods.
Signed-off-by: David Scott <dave.scott@docker.com>
The TCPProxy can proxy from anything which satisfies this interface:
type Conn interface {
io.Reader
io.Writer
io.Closer
CloseRead() error
CloseWrite() error
}
Signed-off-by: David Scott <dave.scott@docker.com>
This package supports a more normal Go interface, in particular it has:
// Listen returns a net.Listener which can accept connections on the given
// vhan port.
func Listen(port uint) (net.Listener, error)
Signed-off-by: David Scott <dave.scott@docker.com>
Note there is a slight name clash between the final binary 'proxy'
and the library formerly known as 'proxy'. Resolve this by calling
the library 'libproxy'.
Signed-off-by: David Scott <dave.scott@docker.com>
This will make it easier to add a vsock interface as well as a regular
TCP/IP one.
As a side-effect, the server is now able to handle more than one concurrent
request!
Signed-off-by: David Scott <dave.scott@docker.com>
This is makes fast shutdown work on Hyper-V
While at it, also clean up whitespaces. The file was mixed
tabs and spaces. Now it uses spaces.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
If bonjour is installed on the host, e.g. via iTunes or some other
program, a lookup for `docker.local` works just like on the Mac.
Just like with LLMNR there seems to be a 4-5 second delay before
Windows decides to do a multicast namelook up, though
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is a bit ugly as we copied and then modified the chronyd init.d
script as shipped in the package.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Busybox ifup does not modify /etc/resolv.conf
Update the hv_set_ifconfig script to overwrite /etc/resolv.conf
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- Don't start hv_fcopy_daemon. It seems to exit and we are not
using it anyway. Also, remove it from the initrd
- Move hv_kvp_daemon and hv_vss_daemon to start earlier
(before networking and docker being started)
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
LLMNR is the Windows equivalent of mDNS.
Import the LLMNR daemon from https://github.com/tklauser/llmnrd
It needed some small modification to compile cleanly on Moby
LLMNRD is only started when running inside a Hyper-V VM
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Upstream commit 598881800825 ("vsock: Fix blocking ops call in
prepare_to_wait") was subsequently reverted in 6f57e56a1527, which said:
The commit reverted with this patch caused us to potentially miss wakeups.
Since the condition is not checked between the prepare_to_wait and the
schedule(), if a wakeup happens after the condition is checked but before
the sleep happens, we will miss it. ( A description of the problem can be
found here: http://www.makelinux.net/ldd3/chp-6-sect-2 ).
The underlying issue has been fixed instead with f7f9b5e7f8ec ("AF_VSOCK:
Shrink the area influenced by prepare_to_wait").
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
A future version of the 9P server will shutdown the forward on 9P
clunk, so if this process crashes the forward will be cleaned up
properly.
Signed-off-by: David Scott <dave.scott@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>
