Feature or enhancement request details
Hey! Believe it or not, this is the first feature request I've ever made on GitHub, so I'd like to start by thanking the community and everyone involved for the great work on this incredible project.
The request is, essentially, an opt-out for the continuous host-to-guest time synchronization that container currently performs. The idea is to let the guest clock be seeded once at boot and then left alone, so that a clock changed manually inside the container isn't overwritten by the host.
Why? To be honest, I have a fairly particular setup that needs testing timedependent behavior and I suspect I'm not alone here. Reproducing clock-skew bugs, testing certificate or license expiry, simulating future dates... there are plenty of reasons to want this. Having a VM changes everything!
In my current use case, I use "--cap-add SYS_TIME" together with "--entrypoint" and my own entry script. The capability is needed to change the date; and because we're running a VM, this doesn't affect the host. The entrypoint script performs, among other things, a conditional "date -s". With this setup, and because the VM is recreated on every stop/start of the container, I propose the following behavior:
- A new "--no-time-sync" flag on container run/create.
- When set, the host stops continuously pushing its clock into the guest after the initial boot.
- The guest clock offset should survive container stop/start. That is, a manual clock change inside the container shouldn't be lost on restart.
- Default behavior (flag unset) is unchanged.
I've actually built this myself and verified a working version locally. It required updating both container and containerization.
In container, to achieve time persistence across restarts, I persist a time offset on stop in a clock.json file. On the next create, if a prior offset exists, it's reapplied before the init process starts.
If the offset file is missing or corrupt, or a capture/restore fails, the start and stop are not prevented.
I'm sharing this approach in case it's useful as a starting point. You may also have other use cases worth keeping in mind before implementing the feature, so we don't miss anything. I'm happy to answer questions about the approach or share the reference diffs if that would help.
Thanks!
Code of Conduct
Feature or enhancement request details
Hey! Believe it or not, this is the first feature request I've ever made on GitHub, so I'd like to start by thanking the community and everyone involved for the great work on this incredible project.
The request is, essentially, an opt-out for the continuous host-to-guest time synchronization that container currently performs. The idea is to let the guest clock be seeded once at boot and then left alone, so that a clock changed manually inside the container isn't overwritten by the host.
Why? To be honest, I have a fairly particular setup that needs testing timedependent behavior and I suspect I'm not alone here. Reproducing clock-skew bugs, testing certificate or license expiry, simulating future dates... there are plenty of reasons to want this. Having a VM changes everything!
In my current use case, I use "--cap-add SYS_TIME" together with "--entrypoint" and my own entry script. The capability is needed to change the date; and because we're running a VM, this doesn't affect the host. The entrypoint script performs, among other things, a conditional "date -s". With this setup, and because the VM is recreated on every stop/start of the container, I propose the following behavior:
I've actually built this myself and verified a working version locally. It required updating both container and containerization.
In container, to achieve time persistence across restarts, I persist a time offset on stop in a clock.json file. On the next create, if a prior offset exists, it's reapplied before the init process starts.
If the offset file is missing or corrupt, or a capture/restore fails, the start and stop are not prevented.
I'm sharing this approach in case it's useful as a starting point. You may also have other use cases worth keeping in mind before implementing the feature, so we don't miss anything. I'm happy to answer questions about the approach or share the reference diffs if that would help.
Thanks!
Code of Conduct