cmd/dockerd: notifyShutdown: don't use Fatal log to prevent early exit
------------------------------------------------------------------------
Commit 40868e263d added this log for situations
where the daemon failed to start, and where no event-log was created
to discover the failure.
However, it used a `Fatal` log which, when using logrus, not only logs
a message, but also calls the [logger's Exit function][1], which defaults
[to `os.Exit`][2].
The error passed to the `notifyShutdown` function can be the result of
different steps in the service's lifecycle; `cli.start()` starts a long-
lived process, and the error returned can be either because it failed
to start the service, or an error produced while shutting down the service.
We should reduce ambiguity here (which could be for `cli.Start()` to return
whether the service was started in the first place). Regardless, we want
code following the log-entry to be executed, to make sure that codepaths
following the `notifyShutdown` (which could be (defer) statements or cleanup
steps) are executed.
This patch changes the log to an `Error`, which is non-fatal, and should
make sure that at least the `service.stopped` is executed to signal the
service no longer running. The logging is also moved out of the
`notifyShutdown`.
Disclaimer: this is with the assumption that calling `service.stopped` is
always acceptable, even if the service is not running, or in other states.
cmd/dockerd: preNotifyReady: return error instead of logging and exit
------------------------------------------------------------------------
Commit 57aef3b490 added support for running
the daemon as a Windows service. As part of this, it introduced a log
for situations where the service failed to start. However, it used a
`Fatal` log for this purpose which, when using logrus, not only logs
a message, but also calls the [logger's Exit function][1], which defaults
[to `os.Exit`][2].
A result of this is that the daemon does an unclean shutdown, causing
other code (which could be (defer) statements or cleanup steps) not to
be executed.
This patch updates the `preNotifyReady` to return the error instead of
logging and exiting. `preNotifyReady` is executed as part of `cli.start()`,
which has an error-return, and the error that is returned, is already
logged by `runDaemon` (so logging it as part of `preNotifyReady` would
result in the error being logged twice).
[1]: 5098132d84/vendor/github.com/sirupsen/logrus/entry.go (L336-L339)
[2]: 5098132d84/vendor/github.com/sirupsen/logrus/logger.go (L342-L348)
- relates to https://github.com/moby/moby/pull/22340
cmd/dockerd: preNotifyReady: return error instead of logging and exit
Commit 57aef3b490 added support for running
the daemon as a Windows service. As part of this, it introduced a log
for situations where the service failed to start. However, it used a
`Fatal` log for this purpose which, when using logrus, not only logs
a message, but also calls the [logger's Exit function][1], which defaults
[to `os.Exit`][2].
A result of this is that the daemon does an unclean shutdown, causing
other code (which could be (defer) statements or cleanup steps) not to
be executed.
This patch changes the `preNotifyReady` to
[1]: 5098132d84/vendor/github.com/sirupsen/logrus/entry.go (L336-L339)
[2]: 5098132d84/vendor/github.com/sirupsen/logrus/logger.go (L342-L348)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We need to isolate the images that we are remapping to a userns, we
can't mix them with "normal" images. In the graph driver case this means
we create a new root directory where we store the images and everything
else, in the containerd case we can use a new namespace.
Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>
Perform the validation when the daemon starts instead of performing these
validations for each individual container, so that we can fail early.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signal systemd when we start shutting down to complement the "READY" notify
that was originally implemented in 97088ebef7
From [sd_notify(3)](https://www.freedesktop.org/software/systemd/man/sd_notify.html#STOPPING=1)
> STOPPING=1
> Tells the service manager that the service is beginning its shutdown. This is useful
> to allow the service manager to track the service's internal state, and present it to
> the user.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Files that are suffixed with `_linux.go` or `_windows.go` are
already only built on Linux / Windows, so these build-tags
were redundant.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch introduces a new experimental engine-level plugin management
with a new API and command line. Plugins can be distributed via a Docker
registry, and their lifecycle is managed by the engine.
This makes plugins a first-class construct.
For more background, have a look at issue #20363.
Documentation is in a separate commit. If you want to understand how the
new plugin system works, you can start by reading the documentation.
Note: backwards compatibility with existing plugins is maintained,
albeit they won't benefit from the advantages of the new system.
Signed-off-by: Tibor Vass <tibor@docker.com>
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
