Skip to content

daemon: add "time-namespaces" feature-flag to disable time-namespaces#52577

Merged
thaJeztah merged 1 commit into
moby:masterfrom
thaJeztah:time_ns_escape_hatch
May 11, 2026
Merged

daemon: add "time-namespaces" feature-flag to disable time-namespaces#52577
thaJeztah merged 1 commit into
moby:masterfrom
thaJeztah:time_ns_escape_hatch

Conversation

@thaJeztah

@thaJeztah thaJeztah commented May 7, 2026

Copy link
Copy Markdown
Member

Add a (temporary) escape-hatch to disable the use of time-namespaces for containers. This allows users to return to the previous default, which unconditionally used the host's time-namespace.

With this patch:

dockerd --feature time-namespaces=false
..
INFO[2026-05-07T21:48:40.840255929Z] time-namespaces disabled through feature-override

- Human readable description for the release notes

Add "time-namespaces" feature flag to disable time-namespaces.

- A picture of a cute animal (not mandatory but encouraged)

@thaJeztah thaJeztah added status/2-code-review kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. impact/changelog area/daemon Core Engine labels May 7, 2026
@thaJeztah thaJeztah added this to the 29.5.0 milestone May 7, 2026
@thaJeztah thaJeztah force-pushed the time_ns_escape_hatch branch from 90d67cb to 159d16c Compare May 7, 2026 22:03
@thaJeztah

Copy link
Copy Markdown
Member Author

Ah. was somewhat expecting that linter to trigger 😂

daemon/daemon_unix.go:1633:55: S1002: should omit comparison to bool constant, can be simplified to !val (staticcheck)
	if val, ok := cfg.Features["time-namespaces"]; ok && val == false {
	                                                     ^

@thaJeztah thaJeztah force-pushed the time_ns_escape_hatch branch 2 times, most recently from 5d1f4aa to f212ab1 Compare May 7, 2026 22:18
@AkihiroSuda

Copy link
Copy Markdown
Member

As in other namespaces, shouldn't this be docker run --timens=(shared|private)?

@thaJeztah

Copy link
Copy Markdown
Member Author

With other namespaces this would allow functionality / behavior to be changed; unless I'm mis-informed, with time namespaces there is (currently) none;

  • offset is zero, so no difference from the host
  • time namespace cannot be modified if it contains a process, so neither host, nor private (container) time-namespace would be mutable

With that taken into account, what purpose would such option currently provide?

Comment thread daemon/daemon_unix.go Outdated

// The "time-namespaces" feature-flag is a (temporary) escape-hatch to disable
// the use of time-namespaces for containers. This allows users to return to the
// previous (pre v29.5.0) default, which unconditionally used the host's time-namespace.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can probably remove the version mentioned here (link below should give context)

Add a (temporary) escape-hatch to disable the use of time-namespaces
for containers. This allows users to return to the previous default,
which unconditionally used the host's time-namespace.

With this patch:

    dockerd --feature time-namespaces=false
    ..
    INFO[2026-05-07T21:48:40.840255929Z] time-namespaces disabled through feature-override

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah

Copy link
Copy Markdown
Member Author

Updated the comment; I added "validate-only" as it was only a comment change

@thaJeztah

Copy link
Copy Markdown
Member Author

I'll bring this one in to at least have the escape-hatch, but still interested to learn from Akihiro if there were specific use-cases we've overlooked, w.r.t.;

As in other namespaces, shouldn't this be docker run --timens=(shared|private)?

With other namespaces this would allow functionality / behavior to be changed; unless I'm mis-informed, with time namespaces there is (currently) none;

  • offset is zero, so no difference from the host
  • time namespace cannot be modified if it contains a process, so neither host, nor private (container) time-namespace would be mutable

With that taken into account, what purpose would such option currently provide?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/daemon Core Engine ci/validate-only impact/changelog kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. status/2-code-review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants