Lei Jitang d09575fb8f Don't create source directory while the daemon is being shutdown, fix #30348
If a container mount the socket the daemon is listening on into
container while the daemon is being shutdown, the socket will
not exist on the host, then daemon will assume it's a directory
and create it on the host, this will cause the daemon can't start
next time.

fix issue https://github.com/moby/moby/issues/30348

To reproduce this issue, you can add following code

```
--- a/daemon/oci_linux.go
+++ b/daemon/oci_linux.go
@@ -8,6 +8,7 @@ import (
        "sort"
        "strconv"
        "strings"
+       "time"

        "github.com/Sirupsen/logrus"
        "github.com/docker/docker/container"
@@ -666,7 +667,8 @@ func (daemon *Daemon) createSpec(c *container.Container) (*libcontainerd.Spec, e
        if err := daemon.setupIpcDirs(c); err != nil {
                return nil, err
        }
-
+       fmt.Printf("===please stop the daemon===\n")
+       time.Sleep(time.Second * 2)
        ms, err := daemon.setupMounts(c)
        if err != nil {
                return nil, err

```

step1 run a container which has `--restart always` and `-v /var/run/docker.sock:/sock`
```
$ docker run -ti --restart always -v /var/run/docker.sock:/sock busybox
/ #

```
step2 exit the the container
```
/ # exit
```
and kill the daemon when you see
```
===please stop the daemon===
```
in the daemon log

The daemon can't restart again and fail with `can't create unix socket /var/run/docker.sock: is a directory`.

Signed-off-by: Lei Jitang <leijitang@huawei.com>

(cherry picked from commit 7318eba5b2f8bb4b867ca943c3229260ca98a3bc)

Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>

Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
2017-06-09 13:13:40 -07:00
2017-05-19 23:20:37 +00:00
2017-05-19 23:20:37 +00:00
2017-05-19 23:20:37 +00:00
2017-05-20 06:06:29 +00:00
2017-05-20 00:22:54 +00:00
2017-06-06 16:54:24 +00:00

Docker CE

This repository hosts open source components of Docker Community Edition (CE) products. The master branch serves to unify the upstream components on a regular basis. Long-lived release branches host the code that goes into a product version for the lifetime of the product.

This repository is solely maintained by Docker, Inc.

Unifying upstream sources

The master branch is a combination of components adapted from different upstream git repos into a unified directory structure using the moby-components tool.

You can view the upstream git repos in the components.conf file. Each component is isolated into its own directory under the components directory.

The tool will import each component git history within the appropriate path.

For example, this shows a commit is imported into the component engine from moby/moby@a27b4b8 into the components/engine directory.

commit 5c70746915d4589a692cbe50a43cf619ed0b7152
Author: Andrea Luzzardi <aluzzardi@gmail.com>
Date:   Sat Jan 19 00:13:39 2013

    Initial commit
    Upstream-commit: a27b4b8cb8e838d03a99b6d2b30f76bdaf2f9e5d
    Component: engine

 components/engine/container.go       | 203 ++++++++++++++++++++++++++++...
 components/engine/container_test.go  | 186 ++++++++++++++++++++++++++++...
 components/engine/docker.go          | 112 ++++++++++++++++++++++++++++...
 components/engine/docker_test.go     | 175 ++++++++++++++++++++++++++++...
 components/engine/filesystem.go      |  52 ++++++++++++++++++++++++++++...
 components/engine/filesystem_test.go |  35 +++++++++++++++++++++++++++
 components/engine/lxc_template.go    |  94 ++++++++++++++++++++++++++++...
 components/engine/state.go           |  48 ++++++++++++++++++++++++++++...
 components/engine/utils.go           | 115 ++++++++++++++++++++++++++++...
 components/engine/utils_test.go      | 126 ++++++++++++++++++++++++++++...
 10 files changed, 1146 insertions(+)

Updates to master branch

Main development of new features should be directed towards the upstream git repos. The master branch of this repo will periodically pull in new changes from upstream to provide a point for integration.

Branching for release

When a release is started for Docker CE, a new branch will be created from master. Branch names will be YY.MM to represent the time-based release version of the product, e.g. 17.06.

Adding fixes to release branch

Note: every commit of a fix should affect files only within one component directory.

Fix available upstream

A PR cherry-picking the necessary commits should be created against the release branch. If the the cherry-pick cannot be applied cleanly, the logic of the fix should be ported manually.

No fix yet

First create the PR with the fix for the release branch. Once the fix has been merged, be sure to port the fix to the respective upstream git repo.

Release tags

There will be a git tag for each release candidate (RC) and general availablilty (GA) release. The tag will only point to commits on release branches.

S
Description
No description provided
Readme 310 MiB
Languages
Go 92%
Shell 5.5%
Dockerfile 1.1%
Go-Checksums 0.9%
Makefile 0.3%
Other 0.2%