Add support for time namespace #1151

KentaTada · 2022-06-20T14:57:30Z

The time namespace is a new kernel feature available in 5.6+ to
isolate the system monotonic and boot-time clocks.

I'm sorry I mistook and closed the existing request #1062

Signed-off-by: Kenta Tada [email protected]

KentaTada · 2022-06-20T15:03:00Z

monotonicNanosecs and boottimeNanosecs do not use the negative number.
And I noticed that the value of offset-nanosecs is not greater than 999,999,999.
So I changed those types from int64 to uint32 in this new PR.

specs-go/config.go

config.md

AkihiroSuda · 2023-01-24T00:43:32Z

@KentaTada could you update the PR?

KentaTada · 2023-01-24T04:51:07Z

@AkihiroSuda @tianon
I updated this pr from your comments.
If I remember correctly, Secs was required and NanoSecs was optional because of the kernel implementation.
But we changed the definition of LinuxTimeOffset from specific to generic. So, I changed Secs to optional.
I may be slow to respond, but I'll check reviews. Sorry.

AkihiroSuda · 2023-01-24T09:41:10Z

config-linux.md

+Entry values are objects with the following properties:
+
+* **`secs`** *(int64, OPTIONAL)* - is the offset of clock (in secs) in the container.
+* **`nanosecs`** *(uint32, OPTIONAL)* - is the additional offset for secs (in nanosecs). The actual offset is secs plus nanosecs.


The actual offset is secs plus nanosecs.

Just to confirm, is this true for negative secs too?

Also curious why nanosecs is unsigned

Hmm. I don't remeber the reason of this explanation.
I just copied the reviewed explanation in the previous PR #1062.
I'll just refer to man and modify it.

First of all,

And I noticed that the value of offset-nanosecs is not greater than 999,999,999.
So I changed those types from int64 to uint32 in this new PR.

The above specification depends on the current implementations.
When we consider future-proof, I'll switch back to int64.

Sorry for going back and forth, but nanosecs can remain unsigned, as it is stated in the kernel man page
https://man7.org/linux/man-pages/man7/time_namespaces.7.html

These offsets are expressed
relative to the clock values in the initial time namespace. The
offset-secs value can be negative, subject to restrictions noted
below; offset-nanosecs is an unsigned value.

No problem. I re-updated to remain unsigned.

marquiz · 2023-01-24T12:00:25Z

config-linux.md

+Entry values are objects with the following properties:
+
+* **`secs`** *(int64, OPTIONAL)* - is the offset of clock (in seconds) in the container.
+* **`nanosecs`** *(int64, OPTIONAL)* - is the offset of clock (in nanoseconds) in the container.


I guess this must be smaller than 10^9(?) Do we want to mention the limits and that this is for fratcions of the seconds?

It's already explained in the kernel doc: https://man7.org/linux/man-pages/man7/time_namespaces.7.html

EINVAL An offset-nanosecs value is greater than 999,999,999.

The time namespace is a new kernel feature available in 5.6+ to isolate the system monotonic and boot-time clocks. Signed-off-by: Kenta Tada <[email protected]>

thaJeztah · 2023-01-24T16:05:23Z

(Silly) questions;

Do Windows containers allow for time to be namespaced? (possibly not for this proposal, but in case it's added to the Windows counterpart in future)
As the discussion above appears to be focussing on signedness and size of integers (because we're trying to do a 1:1 mapping of the Linux kernel to the Spec), I'm wondering if we MUST follow the linux Kernel here, or if it would be beneficial to pick our own definition (does RFC3399 officially support nanoseconds and a "duration", or is there an RFC for that?).

Perhaps it's not an option, and I know many of the options were a 1:1 mapping of kernel features (out of convenience?) I also know that some of those choices made it less agnostic/portable than desired, which is why I was considering if another format would be beneficial / future proof (as long as it's not ambiguous, and documented how runtimes must interpret the config and convert it to (currently) what Linux provides).

AkihiroSuda · 2023-01-25T11:27:00Z

windows

I think windows is out of the scope of this PR, and windows support can be added in the config-windows.md spec separately in the future when somebody needs it.

thaJeztah · 2023-01-25T11:43:18Z

I think windows is out of the scope of this PR, and windows support can be added in the config-windows.md spec separately in the future when somebody needs it.

For sure! Mostly exploring if there's an platform-agnostic way to specify this configuration (and if there is, and it wouldn't be "crippling" either side, the same format could be used for Windows)

AkihiroSuda · 2023-02-01T02:20:49Z

@thaJeztah Can we merge this?

giuseppe · 2023-03-29T20:32:12Z

schema/config-linux.json

+            "timeOffsets": {
+                "type": "object",
+                "additionalProperties": {
+                    "$ref": "defs-linux.json#/definitions/TimeOffsets"
+                }


this doesn't seem correct.

I've opened a PR: #1193

AkihiroSuda · 2023-05-11T02:23:11Z

@KentaTada Do you plan to open a PR for runc (or other runtimes)?

KentaTada · 2023-05-11T03:14:40Z

Hello @AkihiroSuda san

Recently, I don't have enough resources to focus on the container runtime.
But @chethanah and team members are interested in implementing time namespace in runc.
If it is ok to send the PR to runc instead of me, I'll ask him to take over my activity.

KentaTada · 2023-05-11T03:42:52Z

@chethanah san

Especially, I have no idea about the special-handling case for time namespace.
For example, when it comes to IPC namespace, it affects the changeable kernel parameters(fs.mqueue.*)
https://github.com/opencontainers/runc/blob/v1.1.7/libcontainer/configs/validate/validator.go#L184
So we need to investigate the properties related with time namespace at first.
Could you create the new issue in runc? If it is difficult or takes a lot of time, please feel free to ask me in the issue's page.

AkihiroSuda · 2023-05-11T04:05:41Z

issue in runc

Support time namespaces runc#2345

utam0k · 2023-05-11T12:51:34Z

👋 Hi @KentaTada @chanezon FYI: crun's implementation containers/crun#1184

KentaTada requested review from crosbymichael, cyphar, dqminh, giuseppe, hqhq, mrunalp, tianon and vbatts as code owners June 20, 2022 14:57

KentaTada mentioned this pull request Jun 20, 2022

Add support for time namespace #1062

Closed

AkihiroSuda reviewed Jul 10, 2022

View reviewed changes

specs-go/config.go Outdated Show resolved Hide resolved

tianon reviewed Jul 11, 2022

View reviewed changes

config.md Outdated Show resolved Hide resolved

tianon mentioned this pull request Dec 12, 2022

Support time namespaces opencontainers/runc#2345

Closed

KentaTada force-pushed the add-time-namespac branch from 827fc2b to 324f30a Compare January 24, 2023 04:40

KentaTada requested review from kolyshkin and thaJeztah as code owners January 24, 2023 04:40

AkihiroSuda reviewed Jan 24, 2023

View reviewed changes

KentaTada force-pushed the add-time-namespac branch from 324f30a to 5210ede Compare January 24, 2023 11:25

AkihiroSuda approved these changes Jan 24, 2023

View reviewed changes

marquiz reviewed Jan 24, 2023

View reviewed changes

Add support for time namespace

36bb632

The time namespace is a new kernel feature available in 5.6+ to isolate the system monotonic and boot-time clocks. Signed-off-by: Kenta Tada <[email protected]>

KentaTada force-pushed the add-time-namespac branch from 5210ede to 36bb632 Compare January 24, 2023 12:21

AkihiroSuda approved these changes Jan 24, 2023

View reviewed changes

tianon approved these changes Jan 25, 2023

View reviewed changes

AkihiroSuda added this to the v1.1.0 milestone Feb 1, 2023

hqhq approved these changes Feb 1, 2023

View reviewed changes

hqhq merged commit 7301c34 into opencontainers:main Feb 1, 2023

AkihiroSuda mentioned this pull request Mar 28, 2023

Release v1.1.0-rc.2 #1192

Merged

giuseppe reviewed Mar 29, 2023

View reviewed changes

ashu-mehra mentioned this pull request Mar 30, 2023

Correct System.nanotime() value after restore openjdk/crac#53

Closed

1 task

chethanah mentioned this pull request May 22, 2023

Support time namespace opencontainers/runc#3876

Merged

3 tasks

AkihiroSuda mentioned this pull request Jun 26, 2023

Release v1.1.0 #1213

Merged

12 tasks

kwilczynski mentioned this pull request Apr 17, 2024

Time Sync problems after restore VM/Node from snapshot cri-o/cri-o#8033

Closed

champtar mentioned this pull request Jan 22, 2025

time namespace missing opencontainers/runtime-tools#783

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for time namespace #1151

Add support for time namespace #1151

KentaTada commented Jun 20, 2022

KentaTada commented Jun 20, 2022

AkihiroSuda commented Jan 24, 2023

KentaTada commented Jan 24, 2023

AkihiroSuda Jan 24, 2023

KentaTada Jan 24, 2023

KentaTada Jan 24, 2023

AkihiroSuda Jan 24, 2023

KentaTada Jan 24, 2023

marquiz Jan 24, 2023

AkihiroSuda Jan 24, 2023 •

edited

Loading

thaJeztah commented Jan 24, 2023

AkihiroSuda commented Jan 25, 2023

thaJeztah commented Jan 25, 2023

AkihiroSuda commented Feb 1, 2023

giuseppe Mar 29, 2023

AkihiroSuda commented May 11, 2023

KentaTada commented May 11, 2023

KentaTada commented May 11, 2023

AkihiroSuda commented May 11, 2023

utam0k commented May 11, 2023

Add support for time namespace #1151

Add support for time namespace #1151

Conversation

KentaTada commented Jun 20, 2022

KentaTada commented Jun 20, 2022

AkihiroSuda commented Jan 24, 2023

KentaTada commented Jan 24, 2023

AkihiroSuda Jan 24, 2023

Choose a reason for hiding this comment

KentaTada Jan 24, 2023

Choose a reason for hiding this comment

KentaTada Jan 24, 2023

Choose a reason for hiding this comment

AkihiroSuda Jan 24, 2023

Choose a reason for hiding this comment

KentaTada Jan 24, 2023

Choose a reason for hiding this comment

marquiz Jan 24, 2023

Choose a reason for hiding this comment

AkihiroSuda Jan 24, 2023 • edited Loading

Choose a reason for hiding this comment

thaJeztah commented Jan 24, 2023

AkihiroSuda commented Jan 25, 2023

thaJeztah commented Jan 25, 2023

AkihiroSuda commented Feb 1, 2023

giuseppe Mar 29, 2023

Choose a reason for hiding this comment

AkihiroSuda commented May 11, 2023

KentaTada commented May 11, 2023

KentaTada commented May 11, 2023

AkihiroSuda commented May 11, 2023

utam0k commented May 11, 2023

AkihiroSuda Jan 24, 2023 •

edited

Loading