profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/kKronstainBrown/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

IBM-Cloud/docs 140

IBM Cloud product documentation.

ibm-cloud-docs/containers 37

IBM Bluemix Container Service documentation

IBM-Cloud/DevOps-Services-Docs 17

We can help you get it done! Bluemix DevOps Services Content

ibm-cloud-docs/visual-recognition 9

Docs for Watson Visual Recognition

IBM-Cloud/docs-services 8

IBM Bluemix Service 3rd party service docs

ibm-cloud-docs/openwhisk 6

Prod repo for IBM Cloud Functions docs

ibm-cloud-docs/openshift 5

openshift prod

ibm-cloud-docs/appid 3

IBM Cloud App ID documentation

alchemyDocs/docs 0

IBM Bluemix product documentation.

issue commentmoby/moby

[feature] Allow mounting sub-directories of named volumes

I've read all comments in this feature request. There are two users that had tried to provide an implementation for this feature. In both cases, they lacked enough knowledge of Go language. This, in turn, prevented them from creating necessary/required unit tests. They both asked for a help on that and both were ignored by the maintainers of this repo. It is clear that maintainers are not willing to help their helpers :( It seems this feature needs to be closed as Ignored by maintainers. Is there a container runtime that supports this feature already?

zacharysells

comment created time in 4 hours

issue commentmoby/moby

(WSL2) docker build "output clipped, log limit 1MiB reached"

I am able to reproduce the issue using docker build on Mac OS X. Tried to set "log-opts": {"max-size": "50m"} on daemon.json but still no lucky.

fcharron83

comment created time in 5 hours

issue openedmoby/moby

Docker managed plugins: Env variables don't get forwarded to the plugin

Description Dockers managed plugins envs don't get forwarded into the container. Dockers managed plugins system has the capability to set ENV variables, which in turn should get forwarded to the plugin container. This doesn't work.

Reproduce the error

  • (Create a managed docker plugin)[https://docs.docker.com/engine/extend/#developing-a-plugin]
  • Add envs to the plugins config.json
  • Inside the started plugin, try to read the set environment variables

Expected Behaviour You can read the set envs

Actual Behaviour The set envs don't appear in the container (as if they were never set in the first place)

created time in 8 hours

issue commentmoby/moby

docker create take a lot of time or even hung in CreateRWLayer stage with high IO

Update a reproduce method:

  1. Consistant write data to docker root dir's disk or just pull big images with high speed at the same time.
  2. Use iostat -mtx 5 and observe the avgqu-sz metric get high (on my system at when avgqu-sz get more than 8, it will reproduce this problem).
  3. Execute docker createand it will return until avgqu-sz comes down.
zvier

comment created time in 19 hours

pull request commentmoby/moby

[20.10 backport] bump up rootlesskit to v0.14.2 (Fix `Timed out proxy starting the userland proxy.` error with `DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns`)

Bumped into this too. Thanks for taking action so quickly. Waiting on 20.10.7, staying on 20.10.5 until then.

AkihiroSuda

comment created time in 19 hours

Pull request review commentmoby/moby

Dockerfile: install criu from binary repo

 COPY --from=swagger       /build/ /usr/local/bin/ COPY --from=tomlv         /build/ /usr/local/bin/ COPY --from=tini          /build/ /usr/local/bin/ COPY --from=registry      /build/ /usr/local/bin/-COPY --from=criu          /build/ /usr/local/+COPY --from=criu          /usr/sbin/criu /usr/local/bin

We could do something cute like criu="$(which criu)"; ln "$criu" /build/ after the apt-get install :trollface:

kolyshkin

comment created time in a day

issue openedmoby/moby

RemoveContainer failed because of Access is denied error.

Description

In GKE, when an API call is issued to terminate the pod, RemoveContainer started but failed because of the following error: RemoveContainer "[ID]" from runtime service failed: rpc error: code = Unknown desc = failed to remove container "[ID]": Error response from daemon: unable to remove filesystem for [ID]: CreateFile C:\ProgramData\docker\containers[ID][ID]-json.log.2: Access is denied.

Steps to reproduce the issue: This is not consistently happen and happens for Windows containers. It seems that there might be some racing condition caused the failure

Describe the results you received: Container fails to remove and pod is stuck in termination.

Describe the results you expected: Container is removed successfully.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

docker://19.3.14

Output of docker info:

(paste your output here)

Additional environment details (AWS, VirtualBox, physical, etc.): Service: GKE Kernel version: 10.0.17763.1757 OS image: Windows Server 2019 Datacenter Container runtime version: docker://19.3.14 kubelet version: v1.17.17

created time in a day

issue commentmoby/moby

Starting swarm services results in images with `<none>` tag

Thanks for the explanation. My pain points are

  • resolution speed (and thus deployment speed) is slow (might not be related to swarm)
  • non trivial traceability (deeper inspection needed) Probably docker stack deploy --resolve-image=changed ... is what I was looking for and makes this Issue a "nit" for me too. While searching I found #31574. That seems to be a dupe... (https://github.com/moby/moby/issues/31574#issuecomment-286182978)
thaJeztah

comment created time in a day

Pull request review commentmoby/moby

[Carry 38704] Implement exec kill API

 func (s *containerRouter) postContainerExecResize(ctx context.Context, w http.Re  	return s.backend.ContainerExecResize(vars["name"], height, width) }++func (s *containerRouter) postContainerExecKill(ctx context.Context, w http.ResponseWriter, r *http.Request, vars map[string]string) error {+	version := httputils.VersionFromContext(ctx)+	if versions.LessThan(version, "1.42") {+		return errdefs.InvalidParameter(fmt.Errorf("postContainerExecKill requires API version 1.42, but the Docker daemon API version is %s", version))+	}+	if err := httputils.ParseForm(r); err != nil {+		return errdefs.InvalidParameter(err)+	}++	var sig syscall.Signal+	name := vars["name"]++	// If we have a signal, look at it. Otherwise, do nothing+	if sigStr := r.Form.Get("signal"); sigStr != "" {+		var err error+		if sig, err = signal.ParseSignal(sigStr); err != nil {

Is this what we do in the container API? I think we should have this in ContainerExecKill rather than here.

awesomebytes

comment created time in a day

Pull request review commentmoby/moby

[Carry 38704] Implement exec kill API

 func (daemon *Daemon) ContainerExecStart(ctx context.Context, name string, stdin 	select { 	case <-ctx.Done(): 		logrus.Debugf("Sending TERM signal to process %v in container %v", name, c.ID)-		daemon.containerd.SignalProcess(ctx, c.ID, name, int(signal.SignalMap["TERM"]))+		daemon.ContainerExecKill(ctx, name, uint64(signal.SignalMap["TERM"]))

Given that we already have the exec config, it seems better to call the contaunerd API directly than to grab this info again.

awesomebytes

comment created time in a day

Pull request review commentmoby/moby

[Carry 38704] Implement exec kill API

 func (daemon *Daemon) ContainerExecStart(ctx context.Context, name string, stdin 	select { 	case <-ctx.Done(): 		logrus.Debugf("Sending TERM signal to process %v in container %v", name, c.ID)-		daemon.containerd.SignalProcess(ctx, c.ID, name, int(signal.SignalMap["TERM"]))+		daemon.ContainerExecKill(ctx, name, uint64(signal.SignalMap["TERM"]))  		timeout := time.NewTimer(termProcessTimeout) 		defer timeout.Stop()  		select { 		case <-timeout.C:-			logrus.Infof("Container %v, process %v failed to exit within %v of signal TERM - using the force", c.ID, name, termProcessTimeout)-			daemon.containerd.SignalProcess(ctx, c.ID, name, int(signal.SignalMap["KILL"]))+			logrus.Infof("Container %v, process %v failed to exit within %d seconds of signal TERM - using the force", c.ID, name, termProcessTimeout)+			daemon.ContainerExecKill(ctx, name, uint64(signal.SignalMap["KILL"]))

Same as above

awesomebytes

comment created time in a day

Pull request review commentmoby/moby

[Carry 38704] Implement exec kill API

 func (s *containerRouter) postContainerExecResize(ctx context.Context, w http.Re  	return s.backend.ContainerExecResize(vars["name"], height, width) }++func (s *containerRouter) postContainerExecKill(ctx context.Context, w http.ResponseWriter, r *http.Request, vars map[string]string) error {+	version := httputils.VersionFromContext(ctx)+	if versions.LessThan(version, "1.42") {+		return errdefs.InvalidParameter(fmt.Errorf("postContainerExecKill requires API version 1.42, but the Docker daemon API version is %s", version))

nit: s/postContainerExecKill/exec kill/

awesomebytes

comment created time in a day

push eventmoby/moby

Sebastiaan van Stijn

commit sha 9b2f55bc1ca1544e407082bbfc626c4bf1745d7c

update containerd binary to v1.5.0 Welcome to the v1.5.0 release of containerd! The sixth major release of containerd includes many stability improvements and code organization changes to make contribution easier and make future features cleaner to develop. This includes bringing CRI development into the main containerd repository and switching to Go modules. This release also brings support for the Node Resource Interface (NRI). Highlights -------------------------------------------------------------------------------- *Project Organization* - Merge containerd/cri codebase into containerd/containerd - Move to Go modules - Remove selinux build tag - Add json log format output option for daemon log *Snapshots* - Add configurable overlayfs path - Separate overlay implementation from plugin - Native snapshotter configuration and plugin separation - Devmapper snapshotter configuration and plugin separation - AUFS snapshotter configuration and plugin separation - ZFS snapshotter configuration and plugin separation - Pass custom snapshot labels when creating snapshot - Add platform check for snapshotter support when unpacking - Handle loopback mounts - Support userxattr mount option for overlay in user namespace - ZFS snapshotter implementation of usage *Distribution* - Improve registry response errors - Improve image pull performance over HTTP 1.1 - Registry configuration package - Add support for layers compressed with zstd - Allow arm64 to fallback to arm (v8, v7, v6, v5) *Runtime* - Add annotations to containerd task update API - Add logging binary support when terminal is true - Runtime support on FreeBSD *Windows* - Implement windowsDiff.Compare to allow outputting OCI images - Optimize WCOW snapshotter to commit writable layers as read-only parent layers - Optimize LCOW snapshotter use of scratch layers *CRI* - Add NRI injection points cri#1552 - Add support for registry host directory configuration - Update privileged containers to use current capabilities instead of known capabilities - Add pod annotations to CNI call - Enable ocicrypt by default - Support PID NamespaceMode_TARGET Impactful Client Updates -------------------------------------------------------------------------------- This release has changes which may affect projects which import containerd. *Switch to Go modules* containerd and all containerd sub-repositories are now using Go modules. This should help make importing easier for handling transitive dependencies. As of this release, containerd still does not guarantee client library compatibility for 1.x versions, although best effort is made to minimize impact from changes to exported Go packages. *CRI plugin moved to main repository* With the CRI plugin moving into the main repository, imports under github.com/containerd/cri/ can now be found github.com/containerd/containerd/pkg/cri/. There are no changes required for end users of CRI. *Library changes* oci The WithAllCapabilities has been removed and replaced with WithAllCurrentCapabilities and WithAllKnownCapabilities. WithAllKnownCapabilities has similar functionality to the previous WithAllCapabilities with added support for newer capabilities. WithAllCurrentCapabilities can be used to give privileged containers the same set of permissions as the calling process, preventing errors when privileged containers attempt to get more permissions than given to the caller. *Configuration changes* New registry.config_path for CRI plugin registry.config_path specifies a directory to look for registry hosts configuration. When resolving an image name during pull operations, the CRI plugin will look in the <registry.config_path>/<image hostname>/ directory for host configuration. An optional hosts.toml file in that directory may be used to configure which hosts will be used for the pull operation as well host-specific configurations. Updates under that directory do not require restarting the containerd daemon. Enable registry.config_path in the containerd configuration file. [plugins."io.containerd.grpc.v1.cri".registry] config_path = "/etc/containerd/certs.d" Configure registry hosts, such as /etc/containerd/certs.d/docker.io/hosts.toml for any image under the docker.io namespace (any image on Docker Hub). server = "https://registry-1.docker.io" [host."https://public-mirror.example.com"] capabilities = ["pull"] [host."https://docker-mirror.internal"] capabilities = ["pull", "resolve"] ca = "docker-mirror.crt" If no hosts.toml configuration exists in the host directory, it will fallback to check certificate files based on Docker's certificate file pattern (".crt" files for CA certificates and ".cert"/".key" files for client certificates). *Deprecation of registry.mirrors and registry.configs in CRI plugin* Mirroring and TLS can now be configured using the new registry.config_path option. Existing configurations may be migrated to new host directory configuration. These fields are only deprecated with no planned removal, however, these configurations cannot be used while registry.config_path is defined. *Version 1 schema is deprecated* Version 2 of the containerd configuration toml is recommended format and the default. Starting this version, a deprecation warning will be logged when version 1 is used. To check version, see the version value in the containerd toml configuration. version=2 FreeBSD Runtime Support (Experimental) -------------------------------------------------------------------------------- This release includes changes that allow containerd to run on FreeBSD with a compatible runtime, such as runj. This support should be considered experimental and currently there are no official binary releases for FreeBSD. The runtimes used by containerd are maintained separately and have their own stability guarantees. The containerd project strives to be compatible with any runtime which aims to implement containerd's shim API and OCI runtime specification. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

view details

Brian Goff

commit sha 9f2b33f75cb094917c69e03ba101bc0bee8673fb

Merge pull request #42149 from thaJeztah/containerd_binary_1.5 update containerd binary to v1.5.0

view details

push time in a day

PR merged moby/moby

Reviewers
update containerd binary to v1.5.0 area/runtime impact/changelog process/cherry-pick status/2-code-review

Welcome to the v1.5.0 release of containerd!

The sixth major release of containerd includes many stability improvements and code organization changes to make contribution easier and make future features cleaner to develop. This includes bringing CRI development into the main containerd repository and switching to Go modules. This release also brings support for the Node Resource Interface (NRI).

Highlights

Project Organization

  • Merge containerd/cri codebase into containerd/containerd
  • Move to Go modules
  • Remove selinux build tag
  • Add json log format output option for daemon log

Snapshots

  • Add configurable overlayfs path
  • Separate overlay implementation from plugin
  • Native snapshotter configuration and plugin separation
  • Devmapper snapshotter configuration and plugin separation
  • AUFS snapshotter configuration and plugin separation
  • ZFS snapshotter configuration and plugin separation
  • Pass custom snapshot labels when creating snapshot
  • Add platform check for snapshotter support when unpacking
  • Handle loopback mounts
  • Support userxattr mount option for overlay in user namespace
  • ZFS snapshotter implementation of usage

Distribution

  • Improve registry response errors
  • Improve image pull performance over HTTP 1.1
  • Registry configuration package
  • Add support for layers compressed with zstd
  • Allow arm64 to fallback to arm (v8, v7, v6, v5)

Runtime

  • Add annotations to containerd task update API
  • Add logging binary support when terminal is true
  • Runtime support on FreeBSD

Windows

  • Implement windowsDiff.Compare to allow outputting OCI images
  • Optimize WCOW snapshotter to commit writable layers as read-only parent layers
  • Optimize LCOW snapshotter use of scratch layers

CRI

  • Add NRI injection points cri#1552
  • Add support for registry host directory configuration
  • Update privileged containers to use current capabilities instead of known capabilities
  • Add pod annotations to CNI call
  • Enable ocicrypt by default
  • Support PID NamespaceMode_TARGET

Impactful Client Updates

This release has changes which may affect projects which import containerd.

Switch to Go modules

containerd and all containerd sub-repositories are now using Go modules. This should help make importing easier for handling transitive dependencies. As of this release, containerd still does not guarantee client library compatibility for 1.x versions, although best effort is made to minimize impact from changes to exported Go packages.

CRI plugin moved to main repository

With the CRI plugin moving into the main repository, imports under github.com/containerd/cri/ can now be found github.com/containerd/containerd/pkg/cri/. There are no changes required for end users of CRI.

Library changes

oci

The WithAllCapabilities has been removed and replaced with WithAllCurrentCapabilities and WithAllKnownCapabilities. WithAllKnownCapabilities has similar functionality to the previous WithAllCapabilities with added support for newer capabilities. WithAllCurrentCapabilities can be used to give privileged containers the same set of permissions as the calling process, preventing errors when privileged containers attempt to get more permissions than given to the caller.

Configuration changes

New registry.config_path for CRI plugin

registry.config_path specifies a directory to look for registry hosts configuration. When resolving an image name during pull operations, the CRI plugin will look in the <registry.config_path>/<image hostname>/ directory for host configuration. An optional hosts.toml file in that directory may be used to configure which hosts will be used for the pull operation as well host-specific configurations. Updates under that directory do not require restarting the containerd daemon.

Enable registry.config_path in the containerd configuration file.

[plugins."io.containerd.grpc.v1.cri".registry]
   config_path = "/etc/containerd/certs.d"
Configure registry hosts, such as /etc/containerd/certs.d/docker.io/hosts.toml
for any image under the docker.io namespace (any image on Docker Hub).

server = "https://registry-1.docker.io"    

[host."https://public-mirror.example.com"]
  capabilities = ["pull"]                  
[host."https://docker-mirror.internal"]
  capabilities = ["pull", "resolve"]
  ca = "docker-mirror.crt"                 

If no hosts.toml configuration exists in the host directory, it will fallback to check certificate files based on Docker's certificate file pattern (".crt" files for CA certificates and ".cert"/".key" files for client certificates).

Deprecation of registry.mirrors and registry.configs in CRI plugin

Mirroring and TLS can now be configured using the new registry.config_path option. Existing configurations may be migrated to new host directory configuration. These fields are only deprecated with no planned removal, however, these configurations cannot be used while registry.config_path is defined.

Version 1 schema is deprecated

Version 2 of the containerd configuration toml is recommended format and the default. Starting this version, a deprecation warning will be logged when version 1 is used.

To check version, see the version value in the containerd toml configuration.

version=2

FreeBSD Runtime Support (Experimental)

This release includes changes that allow containerd to run on FreeBSD with a compatible runtime, such as runj. This support should be considered experimental and currently there are no official binary releases for FreeBSD. The runtimes used by containerd are maintained separately and have their own stability guarantees. The containerd project strives to be compatible with any runtime which aims to implement containerd's shim API and OCI runtime specification.

- Description for the changelog <!-- Write a short (one line) summary that describes the changes in this pull request for inclusion in the changelog: -->

- A picture of a cute animal (not mandatory but encouraged)

+1 -1

8 comments

1 changed file

thaJeztah

pr closed time in a day

pull request commentmoby/moby

update containerd binary to v1.5.0

Lib update?

Have some branches to update containerd and runc vendoring, but if containerd is keeping its stability guarantee, we should be able to update just the binary (and doing it separate here to verify that)

thaJeztah

comment created time in a day

pull request commentmoby/moby

update containerd binary to v1.5.0

Lib update?

thaJeztah

comment created time in a day

issue commentmoby/moby

Docker checkpoint is restarting the process instead of saving the state.

Downgrading docker using the static binaries does the trick. Ref: checkpoint-restore/criu#1365

chenchix

comment created time in a day

PR opened moby/moby

vendor: github.com/armon/go-metrics: fix broken file permissions

Source files should never have execute permissions.

Signed-off-by: Enrico Weigelt, metux IT consult info@metux.net

<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/moby/moby/blob/master/CONTRIBUTING.md

** Make sure all your commits include a signature generated with git commit -s **

For additional information on our contributing process, read our contributing guide https://docs.docker.com/opensource/code/

If this is a bug fix, make sure your description includes "fixes #xxxx", or "closes #xxxx"

Please provide the following information: -->

- What I did

- How I did it

- How to verify it

- Description for the changelog <!-- Write a short (one line) summary that describes the changes in this pull request for inclusion in the changelog: -->

- A picture of a cute animal (not mandatory but encouraged)

+0 -0

0 comment

4 changed files

pr created time in 2 days

issue commentmoby/moby

Failed to set OOM Score on shim error when running docker:dind in Kubernetes

Now that ... https://github.com/containerd/containerd/releases/tag/v1.5.0 ... is out. That would definitely be the preferred version to sync with for us and likely many teams that are in environments where compliance is an issue.

skaegi

comment created time in 2 days

pull request commentmoby/moby

update containerd binary to v1.5.0

(not sure if we should cherry-pick already though, as we don't have containerd v1.5.x packages yet for the deb/rpm packages)

containerd 1.4 is expected to reach EOL on November, if Docker 20.10 is expected to be maintained after November, Docker 20.10 should update containerd to 1.5 or later to receive security updates.

thaJeztah

comment created time in 2 days

pull request commentmoby/moby

update containerd binary to v1.5.0

(not sure if we should cherry-pick already though, as we don't have containerd v1.5.x packages yet for the deb/rpm packages)

thaJeztah

comment created time in 2 days

pull request commentmoby/moby

update containerd binary to v1.5.0

@tonistiigi @cpuguy83 @tianon PTAL

thaJeztah

comment created time in 2 days

issue openedmoby/moby

In RUN defining secret dst with env var fails

Description I am using the flag --secret in docker build in order to mount secrets into the Dockerfile. When I am trying to consume the secret in the Dockerfile with --mount=type=secret, I can only access it when the destination is an absolute path. When trying to use a env variable in the destination, docker build fails.

Steps to reproduce the issue:

  1. Use the following sample Dockerfile:
FROM debian:buster-slim
ENV WORK_DIR="/project"
WORKDIR $WORK_DIR
RUN --mount=type=secret,id=my-secret,dst=$WORK_DIR/secret.yaml cat $WORK_DIR/secret.yaml
  1. Create a sample secret.yaml file in your current folder, e.g.:
secret1: abc
secret2: def
  1. Run the docker build command: docker build -t simple-test --secret id=my-secret,src=secret.yaml .

Describe the results you received: The following error occurs:

[+] Building 0.5s (6/6) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                   0.0s
 => => transferring dockerfile: 199B                                                                                                                   0.0s
 => [internal] load .dockerignore                                                                                                                      0.0s
 => => transferring context: 2B                                                                                                                        0.0s
 => [internal] load metadata for docker.io/library/debian:buster-slim                                                                                  0.0s
 => [1/3] FROM docker.io/library/debian:buster-slim                                                                                                    0.0s
 => CACHED [2/3] WORKDIR /project                                                                                                                      0.0s
 => ERROR [3/3] RUN --mount=type=secret,id=my-secret,dst=/project/secret.yaml cat /project/secret.yaml                                                 0.3s
------
 > [3/3] RUN --mount=type=secret,id=my-secret,dst=/project/secret.yaml cat /project/secret.yaml:
#6 0.240 cat: /project/secret.yaml: No such file or directory
------
executor failed running [/bin/sh -c cat $WORK_DIR/secret.yaml]: exit code: 1

Describe the results you expected: Since I can see in the error output that the variable $WORK_DIR is correctly interpolated, I would expect that the mount works and the cat command can read the secret-file.

Additional information you deem important (e.g. issue happens only occasionally): When I replace the RUN line with the following one:

RUN --mount=type=secret,id=my-secret,dst=/project/secret.yaml cat $WORK_DIR/secret.yaml

Everything works fine.

Output of docker version:

Client:
 Cloud integration: 1.0.14
 Version:           20.10.6
 API version:       1.41
 Go version:        go1.16.3
 Git commit:        370c289
 Built:             Fri Apr  9 22:46:57 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.6
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8728dd2
  Built:            Fri Apr  9 22:44:56 2021
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
  compose: Docker Compose (Docker Inc., 2.0.0-beta.1)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 55
 Server Version: 20.10.6
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.25-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.844GiB
 Name: docker-desktop
 ID: POSW:2CDU:WHGO:3VYC:C6KS:PL2J:F4SG:VY6G:V7WD:SAND:ZTY7:7GXH
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 42
  Goroutines: 47
  System Time: 2021-05-07T09:06:20.173413102Z
  EventsListeners: 4
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.): Physical on macOS Big Sur Version 11.3

created time in 2 days

pull request commentmoby/moby

Move libnetwork

@cpuguy83 I have no idea why the hnsCall failed in Win32: The specified module could not be found. (0x7e) error appears. The Windows agents are Windows Server 2019 from mid February with Docker 19.03.12 installed. I'm planning to update the agents to have all latest updates and Docker 20.10.6 installed.

cpuguy83

comment created time in 2 days

issue closedmoby/moby

docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "-p"

image

There is a Dockerfile I have built : docker bulid . -t xxx:xxx Then I try create contains : docker run -d xxx:xxx -p 9001:80 but docker does not work Error message
docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "-p": executable file not found in $PATH: unknown.

See the picture above for details~

help me,thankyou

closed time in 2 days

RenJunFeng

issue commentmoby/moby

docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "-p"

docker run -d xxx:xxx -p 9001:80

The correct form is docker run -d -p 9001:80 xxx:xxx

RenJunFeng

comment created time in 2 days

issue openedmoby/moby

docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "-p"

image

There is a Dockerfile I have built : docker bulid . -t xxx:xxx Then I try create contains : docker run -d xxx:xxx -p 9001:80 but docker does not work Error message
docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "-p": executable file not found in $PATH: unknown.

See the picture above for details~

help me,thankyou

created time in 2 days

pull request commentmoby/moby

overlay2: async umount with wrap umount and rmdir in a goroutine

Any one has any other suggestions? Maybe I can change the title async umount with lazy umount. Becuase this umount operation is not needed immediately return for docker create or docker stop.

zvier

comment created time in 2 days

pull request commentmoby/moby

[Carry 38704] Implement exec kill API

The PR is ready for review or hopefully merge again @AkihiroSuda @cpuguy83

The CI failed because of some DNS issue that I believe has nothing to do with this PR.

awesomebytes

comment created time in 2 days

issue commentmoby/moby

Docker 1.12 load balancing always redirecting traffic to the same instance of a service

Is there any updates on this issue?

dchapkine

comment created time in 2 days