Currently we have a problem when buffers are used for std file
descriptors. These buffers are filled from goroutines (Cmd.goroutine),
and we need to wait them to be sure that all data have been copied.
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Move the network setup back into the standard init even for user
namespaces now that mounts are fully supported and working.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Add a rich Error type to the libcontainer package and use it in the API so
that callers can:
* Check for a specific error without depending on an error string,
* Obtain the stack trace of the function or method which detected the error.
The Error type provides a typed error code and a stack trace. The error code
identifies the error and enables the caller to test for it without being
sensitive to changes in the error text. The stack trace identifies the point
at which the error was detected. The combination of error code and stack trace
will enable errors to be diagnosed much more easily and with less guesswork
than when raw string-based errors are used.
The Error type conforms to the error interface and its Error method prints a
short error message. The Detail method provides a verbose error message
including the stack trace.
Notes:
1. There is an unfortunate precedent in the Go standard library which uses
variables to define errors. Checking for a specific error involves a string
comparison and assumes the corresponding variable has not been updated. It is
more robust and efficient to identify errors with integer-based types and
associated constants, although errors should still include a string
description for ease of use by humans.
2. It is not feasible to assign distinct types to Factory and Container
error codes because common errors such as SystemError cannot be declared in
two places and the names of the error codes then need to be decorated. This is
less readable.
Signed-off-by: Steve Powell <spowell@pivotal.io>
Andrey Vagin
Michael Crosby
Steve Powell
Glyn Normington