If STDOUT or STDERR are attached and the container exits, the streams
will be closed by the daemon while the container is exiting, causing
the streamer to return an error
61b02e636d/cli/command/container/hijack.go (L53)
that gets sent
61b02e636d/cli/command/container/run.go (L278)
and received
61b02e636d/cli/command/container/run.go (L225)
on `errCh`.
However, if only STDIN is attached, it's not closed (since this is
attached to the user's TTY) when the container exits, so the streamer
doesn't exit and nothing gets sent on `errCh`, meaning the CLI execution
hangs receiving on `errCh` on L231.
Change the logic to receive on both `errCh` and `statusChan` – this way,
if the container exits, we get notified on `statusChan` (even if only
STDIN is attached), and can cancel the streamer and exit.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Nondistributable artifacts are deprecated, and no longer used; we'll be
deprecating these fields, so let's already skip their use.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Various functions were passing through the API response as a whole, but
effectively only needed it for a status message (if any). Reduce what's
returned to only the message.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- also check errors that were previously not handled
- use the fakeCLI's buffer instead of creating one manually
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Be more explicit on not returning a response if there was an error;
change some non-exported functions to return a pointer, and return
nil instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now, if running in "detached" mode, we early exit at L222.
Similarly, if `attachContainer` errors out, it returns an error that
gets handled on L190.
As such, `errCh` can never be nil on L231. Remove the nil check.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Since everything else after the `apiClient.ContainerStart` block is
under an `if attach` conditional, we can move the "detached" early exit
up.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
During a `docker run`, the CLI has some different behavior/output
depending on whether the run is "detached" or not.
In some cases, the CLI is checking whether either `stdin`, `stdout` or
`stderr` are attached, but in other cases we're only checking `stdout`
and `stderr`, which leads to some inconsistencies:
```
$ docker run -a stdout --rm --name test alpine top
[docker kill test]
exit status 137
$ docker run -a stderr --rm --name test alpine top
[docker kill test]
exit status 137
$ docker run -a stdin --rm --name test alpine top
56820d94a89b96889478241ae68920323332c6d4cf9b51ba9340cba01e9e0565
[docker kill test]
[no exit code]
```
Since we're not checking for whether `stdin` is attached when deciding
whether to early exit without receiving on `statusChan`, the `docker run
-a stdin` is falling into the "detached mode" logic, which simply prints
the container ID and doesn't print/return the exit code.
This patch makes the "attached" checks consistent.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
The Class field was added because Docker Hub registry required a special
scope to be set for pulling plugins;
HTTP/1.1 401 Unauthorized
...
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository(plugin):vieux/sshfs:pull",error="insufficient_scope"
This is no longer a requirement, and the field is no longer set.
updates 0ba820ed0b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Fix a case where one inaccessible plugin search path stops the whole
search and prevents latter paths from being scanned.
Remove a preliminary `Stat` call that verifies whether path is an actual
directory and is accessible.
It's unneeded and doesn't actually check whether the directory can be
listed or not.
`os.ReadDir` will fail in such case anyway, so just attempt to do that
and ignore any encountered error, instead of erroring out the whole
plugin candidate listing.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This patch fixes the context cancellation
behaviour for the `runContainer` function,
specifically the `createContainer` function
introduced in this commit 991b1303da.
It delays stripping the `cancel` from the context
passed into the `runContainer` function so that
the `createContainer` function can be cancelled
gracefully by a SIGTERM/SIGINT.
This is especially true when the requested image
does not exist and `docker run` needs to `pull`
the image before creating the container.
Although this patch does gracefully cancel
the `runContainer` function it does not address
the root cause. Some functions in the call path
are not context aware, such as `pullImage`.
Future work would still be necessary to ensure
a consistent behaviour in the CLI.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
