Start the metadata transaction before creating the overlay2 directory.
This ensures that if driver.Create() fails, we can properly cancel the
transaction. Previously, if StartTransaction() failed after driver.Create()
succeeded, the defer cleanup would not run (not registered yet), leaving
an orphaned overlay2 directory.
The fix reorders operations so that:
1. Transaction is started first (no filesystem changes yet)
2. Overlay2 directory is created second (transaction ready for cleanup)
3. Defer is registered after both succeed (tx is guaranteed non-nil)
If driver.Create() fails, the transaction is explicitly cancelled before
returning. The nil check for tx in the defer is no longer needed since
tx is guaranteed to exist when the defer runs.
Related to moby/moby#45939
Signed-off-by: Jan Scheffler <jan.scheffler@qodev.ai>
Stopping the Engine while a container with autoremove set is running may
leave behind dead containers on disk. These containers aren't reclaimed
on next start, appear as "dead" in `docker ps -a` and can't be
inspected or removed by the user.
This bug has existed since a long time but became user visible with
9f5f4f5a42. Prior to that commit,
containers with no rwlayer weren't added to the in-memory viewdb, so
they weren't visible in `docker ps -a`. However, some dangling files
would still live on disk (e.g. folder in /var/lib/docker/containers,
mount points, etc).
The underlying issue is that when the daemon stops, it tries to stop all
running containers and then closes the containerd client. This leaves a
small window of time where the Engine might receive 'task stop' events
from containerd, and trigger autoremove. If the containerd client is
closed in parallel, the Engine is unable to complete the removal,
leaving the container in 'dead' state. In such case, the Engine logs the
following error:
cannot remove container "bcbc98b4f5c2b072eb3c4ca673fa1c222d2a8af00bf58eae0f37085b9724ea46": Canceled: grpc: the client connection is closing: context canceled
Solving the underlying issue would require complex changes to the
shutdown sequence. Moreover, the same issue could also happen if the
daemon crashes while it deletes a container. Thus, add a cleanup step
on daemon startup to remove these dead containers.
Signed-off-by: Albin Kerouanton <albin.kerouanton@docker.com>
Replace WithDialOpts with WithExtraDialOpts when creating containerd
clients to preserve the containerd client's default dial options while
adding our custom options.
Previously, using WithDialOpts would overwrite all of containerd's
default dial options, requiring us to sync them.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Fixes warning:
```
time="2025-11-06T11:22:30Z" level=warning msg="Template locator \"template://oraclelinux-8\" should be written \"template:oraclelinux-8\" since Lima v2.0"
```
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Add a `dev` target which adds a convenient developer loop which
rebuilds and reruns the daemon after a SIGINT is received.
It can be exited by sending SIGINT (Ctrl+C) a couple times.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This code was added in 85b260fba8, but didn't
account for maps.Clone returning a `nil` map if the map cloned was `nil`.
This could lead to a panic, similar to the panic that was fixed in
7517464283d29969c4d3615397b369abd99ce395;
panic: assignment to entry in nil map
goroutine 498 [running]:
github.com/moby/moby/v2/daemon.buildPortsRelatedCreateEndpointOptions(0x400042f348, 0xaaaabcc8f458?, 0x40006feb40)
/root/build-deb/engine/daemon/network.go:1047 +0x844
github.com/moby/moby/v2/daemon.buildCreateEndpointOptions(0x400042f348, 0x4001015040, 0x400027d320, 0x40006feb40, {0x0, 0x0, 0x4001506cb8?})
/root/build-deb/engine/daemon/network.go:988 +0x20c
github.com/moby/moby/v2/daemon.(*Daemon).connectToNetwork(0x4000898008, {0xaaaabe21d9f8, 0x4000f12b10}, 0x400089a008, 0x400042f348, {0x400077a9f0, 0x6}, 0x400027d320)
/root/build-deb/engine/daemon/container_operations.go:738 +0x66c
github.com/moby/moby/v2/daemon.(*Daemon).allocateNetwork(0x4000898008, {0xaaaabe21d9f8, 0x4000f12b10}, 0x400089a008, 0x400042f348)
/root/build-deb/engine/daemon/container_operations.go:421 +0x298
github.com/moby/moby/v2/daemon.(*Daemon).initializeCreatedTask(0x4000898008, {0xaaaabe21d9f8, 0x4000f12b10}, 0x400089a008, {0xaaaabe23dc60, 0x4000eb21c8}, 0x400042f348, 0xaaaabd4db3df?)
/root/build-deb/engine/daemon/start_linux.go:37 +0x260
github.com/moby/moby/v2/daemon.(*Daemon).containerStart(0x4000898008, {0xaaaabe21d9c0, 0xaaaabfa05300}, 0x400089a008, 0x400042f348, {0x0, 0x0}, {0x0, 0x0}, 0x1)
/root/build-deb/engine/daemon/start.go:242 +0xba8
github.com/moby/moby/v2/daemon.(*Daemon).restore.func4(0x400042f348, 0x400117f1f0)
/root/build-deb/engine/daemon/daemon.go:633 +0x308
created by github.com/moby/moby/v2/daemon.(*Daemon).restore in goroutine 1
/root/build-deb/engine/daemon/daemon.go:607 +0x5ec
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 6aea8c2591 updated this part of the
test to account for BuildKit now being used as default, which doesn't use
regular containers to "commit" to an image, and therefore doesn't produce
events as part of the build.
However, it changed it to filter for `build` type events, which .. don't
exist. The test passed because it only checked for number of events produced,
which is approximated by checking the number of lines in the output. In
this case, the output would be empty, so "events" was a slice of strings
with length 1; an empty string.
Given that BuildKit doesn't produce meaningful events to test for, we could
either disable BuildKit, to test the legacy builder, or just remove this
part of the test. Let's do the latter.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
