When a plugin has an activation error, it was not being checked in the
`waitActive` loop. This means it will just wait forever for a manifest
to be populated even though it may never come.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit f2d384fca6)
Signed-off-by: Victor Vieux <vieux@docker.com>
Upon each container create I'm seeing these warning **every** time in the
daemon output:
```
WARN[0002] Your kernel does not support swap memory limit
WARN[0002] Your kernel does not support cgroup rt period
WARN[0002] Your kernel does not support cgroup rt runtime
```
Showing them for each container.create() fills up the logs and encourages
people to ignore the output being generated - which means its less likely
they'll see real issues when they happen. In short, I don't think we
need to show these warnings more than once, so let's only show these
warnings at daemon start-up time.
Signed-off-by: Doug Davis <dug@us.ibm.com>
(cherry picked from commit ff42a2eb41)
Signed-off-by: Victor Vieux <vieux@docker.com>
c54b717 caused a regression for pluginv1 on Windows, where extraneous
backslashes were added to BasePath of the plugin. For pluginv1 on windows,
BasePath() should return an empty string, since the plugin is fully aware
of the mount path. Also, unlike Linux where all paths are relative to "/",
Windows paths are dependent on system drives and mapped drives.
Fixes#30148
Signed-off-by: Anusha Ragunathan <anusha.ragunathan@docker.com>
(cherry picked from commit 0ef21eb0e3)
Signed-off-by: Victor Vieux <vieux@docker.com>
`plugins.GetAll()` was not locking the plugin map when checking if a
plugin exists, this can cause a race and potentially a panic if another
goroutine is trying to load a plugin into the map at the same time.
Also fixes a race during activation where a plugin inserts itself into
the plugin map but does not check if something else is already there.
This is already checked before trying to activate the plugin, however
the map lock is not held for this entire period, so other plugins may be
loaded during this time.
To fix, before inserting the plugin into the map, check if one with the
same name already exists and use that instead.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 21fcbb39b7)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
When a plugin is activated, and then `plugins.Handle` is called to
register a new handler for a given plugin type, a deadlock occurs when
for anything which calls `waitActive`, including `Get`, and `GetAll`.
This happens because `Handle()` is setting `activated` to `false` to
ensure that plugin handlers are run on next activation.
Maybe these handlers should be called immediately for any plugins which
are already registered... but to preserve the existing behavior while
fixing the deadlock, track if handlers have been run on plugins and
reset when a new handler is registered.
The simplest way to reproduce the deadlock with Docker is to add a `-v
/foo` to the test container created for the external graphdriver tests.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 2938dce794)
Signed-off-by: Victor Vieux <vieux@docker.com>
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
The current GetAll handles both V2 and legacy plugins. Also due to the
nature of V1 plugins, it also loads them. This causes problems when
loading is not required. Hence adding an independent API that will
return only the plugins that are loaded using v2 mangaed plugins.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Move plugins to shared distribution stack with images.
Create immutable plugin config that matches schema2 requirements.
Ensure data being pushed is same as pulled/created.
Store distribution artifacts in a blobstore.
Run init layer setup for every plugin start.
Fix breakouts from unsafe file accesses.
Add support for `docker plugin install --alias`
Uses normalized references for default names to avoid collisions when using default hosts/tags.
Some refactoring of the plugin manager to support the change, like removing the singleton manager and adding manager config struct.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
(cherry picked from commit 3d86b0c79b)
Adds 2 new methods to v2 plugin `Acquire` and `Release` which allow
refcounting directly at the plugin level instead of just the store.
Since a graphdriver is initialized exactly once, and is really managed
by a separate object, it didn't really seem right to call
`getter.Get()` to refcount graphdriver plugins.
On shutdown it was particularly weird where we'd either need to keep a
driver reference in daemon, or keep a reference to the pluggin getter in
the layer store, and even then still store extra details on if the
graphdriver is a plugin or not.
Instead the plugin proxy itself will handle calling the neccessary
refcounting methods directly on the plugin object.
Also adds a new interface in `plugingetter` to account for these new
functions which are not going to be implemented by v1 plugins.
Changes terms `plugingetter.CREATE` and `plugingetter.REMOVE` to
`ACQUIRE` and `RELEASE` respectively, which seems to be better
adjectives for what we're doing.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit f29bbd16f5)
Signed-off-by: Victor Vieux <vieux@docker.com>
Legacy plugins expect host-relative paths (such as for Volume.Mount).
However, a containerized plugin cannot respond with a host-relative
path. Therefore, this commit modifies new volume plugins' paths in Mount
and List to prepend the container's rootfs path.
This introduces a new PropagatedMount field in the Plugin Config.
When it is set for volume plugins, RootfsPropagation is set to rshared
and the path specified by PropagatedMount is bind-mounted with rshared
prior to launching the container. This is so that the daemon code can
access the paths returned by the plugin from the host mount namespace.
Signed-off-by: Tibor Vass <tibor@docker.com>
(cherry picked from commit c54b717caf)
Signed-off-by: Victor Vieux <vieux@docker.com>
Because .. `hardcore_hamilton` and `inspiring_murdock`
https://twitter.com/swiftonsecurity/status/801195049165799424
Also replacing adjectives that could be interpreted as
refering to body size, (mental) health, intoxication.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 169b4d92a1)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
Dump stack dumps to exec root instead of daemon root.
When no path is provided to the stack dumper, such is the case with
SIGQUIT, dump to stderr.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 0bd720b28d)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
change reading order from beginning at the end to beginning at a buffer start
added intergration tests for boundary cases
Removed whitespace
Signed-off-by: Shayne Wang <shaynexwang@gmail.com>
The ANSI escape codes \e[0A (cursor up 0 lines) and \e[0B (cursor down 0 lines)
are not well defined and are treated differently by different terminals. In
particular xterm treats 0 as a missing parameter and therefore defaults to 1,
whereas rxvt-unicode treats these escapes as a request to move 0 lines.
However the use of these codes is unnecessary and were really just hiding the
fact that we were not correctly computing diff when adding a new line. Having
added the new line to the ids map and output the corresponding \n we need to
then calculate a correct diff of 1 rather than leaving it as the default 0
(which xterm then interprets as 1). The fix is to pull the diff calculation out
of the else case and to always do it.
With this in place we can then avoid outputting escapes for moving 0 lines.
Actually diff should never be 0 to start with any more, but check to be safe.
This fixes corruption of `docker pull` seen with rxvt-unicode (and likely other
terminals in that family) seen in #28111. Tested with rxvt-unicode
($TERM=rxvt-unicode), xterm ($TERM=xterm), mlterm ($TERM=mlterm) and aterm
($TERM=kterm).
The test cases have been updated to match the new behaviour.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This remove a dependency on `go-check` (and more) when using
`pkg/idtools`. `pkg/integration` should never be called from any other
package then `integration`.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
In some cases, attempting to `docker cp` to a container's volume dir
would fail due to the volume mounts not existing after performing a
bind-mount on the container path prior to doing a pivot_root.
This does not seem to be effecting all systems, but was found to be a
problem on centos.
The solution is to use an `rbind` rather than `bind` so that any
existing mounts are carried over.
The `MakePrivate` on `path` is no longer neccessary since we are already
doing `MakeRPrivate` on `/`.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
