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>
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>
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>
