Resource Saver enabled by default after upgrade to v4.62.0 silently shuts down Docker engine after 5 min idle

[debugmcpdev]

Description

After upgrading Docker Desktop from v4.58.0 to v4.62.0 on Windows, the Resource Saver feature (useResourceSaver) is enabled by default with a 5-minute idle timeout (autoPauseTimeoutSeconds: 300). This causes the entire Docker engine and backend to shut down silently after 5 minutes of inactivity.

This is a breaking change in behavior for users upgrading from previous versions where this feature did not exist or was not enabled.

Impact

• The Docker engine shuts down completely — not just the UI, but the daemon itself
• docker CLI commands fail with Cannot connect to the Docker daemon
• No user-visible notification or warning is shown before or during shutdown
• Containers stop running, breaking CI/CD pipelines, dev environments, and any tooling that depends on Docker being available
• The Electron UI log shows no error or shutdown message — it simply stops logging, making it very difficult to diagnose
• The only clue is monitor exited: exit status 1 buried in the backend monitor log

Steps to Reproduce

1. Have Docker Desktop v4.58.0 (or earlier) running normally
2. Allow Docker Desktop to auto-update to v4.62.0
3. After the update completes, leave Docker idle for ~5 minutes (no container operations)
4. Observe: Docker engine shuts down, UI disappears, docker ps fails

Expected Behavior

• Upgrading Docker Desktop should not silently change idle behavior that causes the engine to shut down
• If Resource Saver is to be enabled by default on new installs, it should not be force-enabled on upgrades from versions that didn't have it
• At minimum, a notification/toast should be shown explaining that Resource Saver is now active and how to disable it
• The shutdown should be clearly logged in the Electron log (not just a silent stop)

Suggested Fix

One or more of:

1. Do not enable Resource Saver by default on upgrades — only on fresh installs
2. Show a one-time notification after upgrade explaining the new feature and how to configure it
3. Log a clear message in the Electron log when Resource Saver triggers a shutdown (e.g., [ResourceSaver] Shutting down Docker engine after 300s of inactivity)
4. Increase the default timeout — 5 minutes is very aggressive for development workflows where you might pause to write code, review docs, etc.

Workaround

Disable Resource Saver via Docker Desktop UI: Settings > Resources > Resource Saver > OFF

Or via the backend API named pipe:

$pipe = New-Object System.IO.Pipes.NamedPipeClientStream('.', 'dockerBackendApiServer', 'InOut')
$pipe.Connect(5000)
$w = New-Object System.IO.StreamWriter($pipe)
$body = '{"desktop":{"useResourceSaver":false}}'
$req = "POST /app/settings HTTP/1.1`r`nHost: localhost`r`nContent-Type: application/json`r`nContent-Length: $($body.Length)`r`n`r`n$body"
$w.Write($req); $w.Flush(); Start-Sleep 1; $pipe.Close()

Environment

• Docker Desktop: v4.62.0 (upgraded from v4.58.0)
• Docker Engine: v29.2.1
• OS: Windows 11 Pro (Build 26200)
• Previous behavior: Docker engine stayed running indefinitely regardless of idle state

[bgronek]

This is still happening. In fact, after a recent update, the resource saver was defaulted to shut down after 30 seconds of CPU idle time.

[ctalledo]

Hi @debugmcpdev, thanks for filing the issue and apologies for the delay in responding.

Strange you are seeing Resource Saver problems on upgrade from 4.58->4.62, since Resource Saver GA'd back in 4.22 and hasn't changed recently.

It's on by default, with a timeout of 5 minutes, but this should almost be transparent to users because it automatically stops the engine when there's no activity (e.g., no containers running) and automatically starts the engine whenever the user starts a container via "docker run" or "docker build" (or more generally performs an action that requires the engine to run).

Also, it's disabled for Docker Desktop with WSL, because the WSL VM is not owned by Docker.

Are you still seeing problems with the feature? If so, please upload a Docker Desktop diagnostics bundle so we can investigate.

[ctalledo]

Hi @bgronek, thanks for chiming in.

This is still happening. In fact, after a recent update, the resource saver was defaulted to shut down after 30 seconds of CPU idle time.

Strange, the resource saver feature defaults to a 5 minute timeout. This hasn't changed. What version of Docker Desktop are you using?

[jeffrson]

BTW, it's not transparent to users: as soon as ressource saver activates, the docker command vanishs from the distribution (*), until engine starts (play button beneath ressource saver message). Until I realized this I restarted the whole application.

Now with 4.81 I have to re-activate every five minutes for docker build. I guess a workaround would be to start a container or disable ressource saver all together, but thats probably not how it should work...

(*) sometimes instead this error message is shown:

→ docker buildx build...
SIGBUS: bus error
PC=0x475d12 m=8 sigcode=2 addr=0x35f5072

goroutine 0 gp=0x4140c684b40 m=8 mp=0x4140c5e6008 [idle]:
runtime.step({0x35f5072?, 0x4140c6bdb88?, 0x4753fa?}, 0x317e50f?, 0x0?, 0x0?)
        runtime/symtab.go:1288 +0x12 fp=0x4140c6bdab0 sp=0x4140c6bdaa0 pc=0x475d12
runtime.pcvalue({0x0?, 0x0?}, 0x4b4652, 0x187aed5?, 0x1)
        runtime/symtab.go:1082 +0x21a fp=0x4140c6bdb80 sp=0x4140c6bdab0 pc=0x4753fa
runtime.pcdatavalue({0x1?, 0x400000000000000?}, 0x40cbd40?, 0x3c24e60?)
        runtime/symtab.go:1244 +0x2e fp=0x4140c6bdbb8 sp=0x4140c6bdb80 pc=0x475bae
runtime.(*stkframe).getStackMap(0x4140c6bdd28, 0x8?)
        runtime/stkframe.go:172 +0x85 fp=0x4140c6bdc90 sp=0x4140c6bdbb8 pc=0x472545
runtime.scanframeworker(0x4140c6bdd28, 0x4140c6bdd88, 0x4140c241260)
        runtime/mgcmark.go:1118 +0x6f fp=0x4140c6bdcf0 sp=0x4140c6bdc90 pc=0x435eef
runtime.scanstack(0x4140c19a1e0, 0x4140c241260)
        runtime/mgcmark.go:973 +0x2c7 fp=0x4140c6bde08 sp=0x4140c6bdcf0 pc=0x435a27
runtime.markroot.func1()
        runtime/mgcmark.go:306 +0xb1 fp=0x4140c6bde58 sp=0x4140c6bde08 pc=0x434491
runtime.markroot(0x4140c241260, 0x16, 0x1)
        runtime/mgcmark.go:280 +0x1a5 fp=0x4140c6bdf08 sp=0x4140c6bde58 pc=0x4340e5
runtime.gcDrain(0x4140c241260, 0x7)
        runtime/mgcmark.go:1275 +0x4a7 fp=0x4140c6bdf78 sp=0x4140c6bdf08 pc=0x4365e7
runtime.gcDrainMarkWorkerIdle(...)
        runtime/mgcmark.go:1168
runtime.gcBgMarkWorker.func2()
        runtime/mgc.go:1881 +0x67 fp=0x4140c6bdfc8 sp=0x4140c6bdf78 pc=0x432327
runtime.systemstack(0x0)
        runtime/asm_amd64.s:562 +0x4a fp=0x4140c6bdfd8 sp=0x4140c6bdfc8 pc=0x492fca

goroutine 8 gp=0x4140c702000 m=8 mp=0x4140c5e6008 [GC worker (active)]:
runtime.systemstack_switch()
        runtime/asm_amd64.s:516 +0x8 fp=0x4140c24bf40 sp=0x4140c24bf30 pc=0x492f68
runtime.gcBgMarkWorker(0x4140c29b880)
        runtime/mgc.go:1847 +0x1df fp=0x4140c24bfc8 sp=0x4140c24bf40 pc=0x43215f
runtime.gcBgMarkStartWorkers.gowrap1()
        runtime/mgc.go:1695 +0x17 fp=0x4140c24bfe0 sp=0x4140c24bfc8 pc=0x431f57
runtime.goexit({})
        runtime/asm_amd64.s:1771 +0x1 fp=0x4140c24bfe8 sp=0x4140c24bfe0 pc=0x494a21
created by runtime.gcBgMarkStartWorkers in goroutine 1
        runtime/mgc.go:1695 +0x105

goroutine 1 gp=0x4140c19a1e0 m=0 mp=0x4297520 [GC assist marking (scan), locked to thread]:
runtime.systemstack_switch()
        runtime/asm_amd64.s:516 +0x8 fp=0x4140c6dda68 sp=0x4140c6dda58 pc=0x492f68
runtime.gcAssistAlloc(0x4140c19a1e0)
        runtime/mgcmark.go:638 +0x2a5 fp=0x4140c6ddaf8 sp=0x4140c6dda68 pc=0x434dc5
runtime.deductAssistCredit(0x10?)
        runtime/malloc.go:1861 +0x46 fp=0x4140c6ddb18 sp=0x4140c6ddaf8 pc=0x425ec6
runtime.mallocgc(0x10, 0x20a36a0, 0x1)
        runtime/malloc.go:1113 +0x67 fp=0x4140c6ddb48 sp=0x4140c6ddb18 pc=0x48a3e7
runtime.newobject(0x21f9f80?)
        runtime/malloc.go:2157 +0x25 fp=0x4140c6ddb70 sp=0x4140c6ddb48 pc=0x425fa5

Edit: even while we are working with docker (docker images, docker info) the "Ressource Saver" becomes active and steals the docker executable from the distribution. This may be proven by watch docker info inside WSL.

[sloshy]

Seeing a variant of this on 4.81.0, Windows on ARM.

Environment: Docker Desktop 4.81.0 (auto-updated from 4.69.0), Windows 11 Home
ARM64 build 26200.8655 (Snapdragon), WSL 2.6.3.0, kernel 6.6.87.2-1

Symptoms: After the 4.81 update, the idle shutdown stops the Docker
engine and it force-kills the entire shared WSL2 utility VM, taking down my personal
Ubuntu distro and every open WSL terminal with it. Per the Resource Saver docs, on
WSL it should only pause the engine inside the docker-desktop distro, not stop the VM.

Notably, settings-store.json already contains "UseResourceSaver": false, but the
idle monitor still initializes and fires, so the opt-out appears to be ignored in 4.81.

Log evidence (com.docker.backend.exe.log + vm/init.log): after resuming from
overnight sleep, "idle mode activated" fired ~30s after each engine start — 13 times
in 10 minutes — each immediately followed by "terminating main distribution" /
"terminating WSL data distro", with the whole VM rebooting 1–2 seconds later:

• idle mode activated 13:16:36.20 → VM boot 13:16:37.89
• idle mode activated 13:16:56.09 → VM boot 13:16:59.03

The Ubuntu distro's systemd journal shows matching unclean-shutdown corruption.

Secondary failure: each hard kill can orphan the backend's AF_UNIX socket files
(%LOCALAPPDATA%\Docker\run\dockerInference,
%LOCALAPPDATA%\docker-secrets-engine\engine.sock). Windows then can't delete them
("The file cannot be accessed by the system"), so the backend crash-loops at startup
with "starting services: initializing Inference manager / Secrets Engine: listening
on unix://...: remove ...: The file cannot be accessed by the system." Workaround:
quit Docker and rename the containing directories aside; they're only deletable
after a reboot.

Diagnostics ID: A182CA1D-8BF7-4926-A47A-36C1156C5F2D/20260713142832