We distinguish export suitability requests from bind mount suitability
requests in the transfuse control protocol. This distinction allows us to
permit both bind mounts of empty directories and export mounts onto empty
directories. Addresses docker/pinata#4213.
Signed-off-by: David Sheets <dsheets@docker.com>
This is less to do with installing modules (which we generally don't expect to
use in Moby) but to populate /lib/modules/`uname -r`/modules.builtin which
turns:
moby:~# modprobe ip_vs
modprobe: FATAL: Module ip_vs not found in directory /lib/modules/4.4.14-moby
moby:~# modprobe nf_nat
modprobe: FATAL: Module nf_nat not found in directory /lib/modules/4.4.14-moby
moby:~#
into:
moby:~# modprobe ip_vs
moby:~# modprobe nf_nat
moby:~#
which reduces the amount noise in the logs, e.g. in docker.log:
time="2016-07-04T11:21:58Z" level=warning msg="Running modprobe nf_nat failed with message: `modprobe: WARNING: Module nf_nat not found in directory /lib/modules/4.4.14-moby`, error: exit status 1"
A fair number of these appear in the logs.
This also stops various tools logging about /lib/modules/`uname -r` not
existing (there was one in the boot log until recently I think)
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Avoid doing this on non-Docker-for-{Mac,Win} editions (which don't run vsudd)
by checking for vsudd.pid and avoid doing it on Docker-for-Win (for now) by
checking for /sys/bus/vmbus (as /etc/init.d/vsudd does too).
Ideally we would just check for /var/run/syslog.vsock but this may not have
arrived yet (typically vsudd is now started immediately prior to syslog and it
forks via start-stop-daemon and thus before it creates the socket). Since
syslogd will reopen as needed we don't want to delay boot either here or in the
vsudd initscript to await the arrival of the socket.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This means that with the previous patches normal vsudd logging will be logged
on the console. The exceptional case of error logging during syslog forwarding
established in the previous patch remains in place.
Prior to this the vsudd.log was actually in /run/vsudd.log and not in /var/log/
(exported to the host) as expected. Prior to c5940b3479 ("Bind the original
/var/log onto /run/log") the log was simply shadowed under the fuse mount over
/var/log.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This is mac only (for now) and will not actually do anything until syslogd is
told to forward to /var/run/syslog.vsock.
syslog uses a SOCK_DGRAM connection to /var/run/syslog.vsock, however vsock
today is SOCK_STREAM only, so we need to "packetise" the stream. Do so by
writing the datagram length as a (little-endian) uint32 before the data itself.
This is slightly modelled after rfc6587 (syslog over TCP) but simplified by
using a 4-byte binary value rather than ASCII digits.
Arrange for vsudd to start before the logger so it is ready and waiting.
Note that the code in vsyslog.go needs to be rather careful about its own
logging, in particular logging forwarding failures over syslog seems likely to
make things worse. Instead this file logs to the console when errors occur,
this will be captured by the logging of the hyperkit VM console.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Rather than hardcoding a single vsock<->docker.sock mapping allow arbitrary
incoming connection forwarding between vsocks and unix domain sockets.
The intention was to subsequently extend this further to support arbitrary
forwarding of outgoing connections too and to use that to forward the syslog
socket out to a vsock.
This turned out not to be a good plan, partly since the syslog socket needs to
be SOCK_DATAGRAM but vsocks only does SOCK_STREAM today (meaning we need some
additional framing here) and partly because handling syslog forwarding in
common code makes error logging in the common code somewhat trickier (logging
syslog errors over syslog).
So instead syslog will be handled as a special case in a following patch.
However some vestiges of the original plan remain, e.g. the inForwards name and
the net field in the forwards which could be unixgram but currently is only
supporting unix(stream).
In principal this patch could be dropped, but it adds some flexibility which
might be useful in the future.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
EAFNOTSUPPORT likely means we are running on a hypervisor which doesn't support
that particular socket type.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
- try several wget's on well known IP addresses to check IP
connectivity (ping in hostnet mode is not good enough)
- try DNS lookup on a well known server
- add service-port-opener logs
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The Windows start script polls the VM for it's IP address before
initiating things like CIFS mounts. Getting the IP config is
done via the KVP daemon. Starting it earlier reduce the start up
delay, in particular if the VM is part of a swarm.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Increase the number of hypervisors where Moby can run and detect
the disks. With this change, I'm able to boot under KVM and see
the disk detected, formatted and mounted as expected.
For the "no error if existing" rather than "make parents" affect. Otherwise:
moby:~# service docker restart
* Stopping docker
* Starting Docker ...
mkdir: can't create directory '/run/log': File exists
[ ok ]
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Building on Debian where /bin/sh is dash:
make[1]: Leaving directory '/home/ijc/development/Docker/moby.git/alpine/packages/docker/docker.git'
mkdir -p bin
cp docker.git/bundles/latest/binary-daemon/{dockerd,docker-runc} bin/
cp: cannot stat 'docker.git/bundles/latest/binary-daemon/{dockerd,docker-runc}': No such file or directory
Makefile:9: recipe for target 'bin' failed
Pasting the construct into a file and running checkbashsisms:
possible bashism in foo line 2 (brace expansion):
cp docker.git/bundles/latest/binary-daemon/{dockerd,docker-runc} bin/
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This allows the proxy to be run easily from a terminal or other script
without requiring fd 3 to be open and writable.
Signed-off-by: David Scott <dave.scott@docker.com>
When running moby under other hypervisors, requiring troubleshooting on
the serial port can be painful. This change enables console support on
tty1 similar to the way prior boot2docker images worked.
