Repository navigation
Conversation
Add daemon configuration options to set a default restart policy for
containers and optionally enforce it.
New configuration options in daemon.json:
- default-restart-policy: Sets the default restart policy for containers
that don't specify one. Defaults to "no" for backward compatibility.
- enforce-default-restart-policy: When enabled, prevents containers from
using a different restart policy than the daemon default. Requests with
a non-matching policy are rejected with an error.
Example daemon.json configuration:
{
"default-restart-policy": {
"Name": "no"
},
"enforce-default-restart-policy": true
}
This provides operators with centralized control over container restart
behavior, addressing use cases where:
- Organizational policy requires specific restart behavior
- External resource management systems have expectations about process
lifecycle (e.g., batch schedulers, orchestrators, cgroup managers)
- Security policies mandate controlled container restart behavior
- Multi-tenant environments need to prevent certain restart policies
Related to moby#52675 (daemon-managed container default profiles)
Signed-off-by: John Robbins <John.Robbins@amd.com>
| // DefaultRestartPolicy is the default restart policy for containers that | ||
| // do not have a container-specific restart policy set. If not specified, | ||
| // defaults to "no" (RestartPolicyDisabled). | ||
| DefaultRestartPolicy containertypes.RestartPolicy `json:"default-restart-policy,omitempty"` |
There was a problem hiding this comment.
I don't think we should add a specific setting for this. This could be handled via the general mechanism of #52675
| // EnforceDefaultRestartPolicy, when enabled, prevents users from overriding | ||
| // the default restart policy. Useful for batch scheduling systems (e.g., SLURM) | ||
| // where restart policies conflict with cgroup lifecycle management. | ||
| EnforceDefaultRestartPolicy bool `json:"enforce-default-restart-policy,omitempty"` |
There was a problem hiding this comment.
I think this is too narrow as a daemon-wide configuration. The real need is the possibility to perform arbitrary checks against the containers.
We should expose this as an extension point, see: #54002
thaJeztah
left a comment
thaJeztah
left a comment
There was a problem hiding this comment.
I want to have a closer look at the overall design (around defaults, and potentially "templates / profiles"). There's been prior discussions around this (also with, e.g. the host.docker.internal magic domain) around changing daemon default behavior, as in some cases it could change the behavior between daemons (resulting in "it worked on my machine, but failed in prod").
restart-policies especialy should be looked at in this case; if a default means (e.g.) "all containers get a always restart policy", this could potentially cause unexpected results. Note that the daemon used to have a --restart flag, which would restart all containers on start; this was deprecated when restart-policies were added. There's also still problems with the restart-policy overall design (#18473 (comment)) that we should look into.
Summary
This PR adds daemon-level default restart policy configuration through two new options:
default-restart-policy: Sets a default restart policy for containers when no explicit policy is specifiedenforce-default-restart-policy: When enabled, rejects container creation with a different restart policyProblem
In resource-managed environments, containers with restart policies can survive external process cleanup, causing resource leaks:
When the resource manager terminates processes in the cgroup, Docker's restart policy races with cgroup cleanup. If Docker restarts the container before the cgroup is destroyed, the container survives and consumes unaccounted resources.
Solution
Cluster operators can configure the daemon to enforce
restart=noon all containers:{ "default-restart-policy": {"Name": "no"}, "enforce-default-restart-policy": true }This prevents the restart race by rejecting containers that specify restart policies.
Behavior:
AI Disclosure: This PR was developed with substantial assistance from Claude Code (Anthropic). AI was used for:
All AI-generated content was reviewed, edited, and tested by the human maintainer.
Release notes