Closed cfergeau closed 5 months ago
@cfergeau this we used for time sync on the mac right?
@cfergeau this we used for time sync on the mac right?
Yes. Maybe this can be solved in a simpler way with makestep -1
in chrony configuration, I haven't re-tested this.
makestep -1
Just looked the man chrony.conf
and got following which sound promising and we don't need to that configuration of the guest-agent if that works as expected, how does podman machine handle time drift in mac?
Normally chronyd will cause the system to gradually correct any time offset, by slowing down or speeding up the
clock as required. In certain situations, e.g. when chronyd is initially started, the system clock might be so
far adrift that this slewing process would take a very long time to correct the system clock.
This directive forces chronyd to step the system clock if the adjustment is larger than a threshold value, but
only if there were no more clock updates since chronyd was started than the specified limit. A negative value
disables the limit.
On most systems it is desirable to step the system clock only on boot, before starting programs that rely on
time advancing monotonically forwards.
An example of the use of this directive is:
makestep 0.1 3
This would step the system clock if the adjustment is larger than 0.1 seconds, but only in the first three
clock updates.
Should we create an issue and set it as good first one
for some new team members to try it out?
Just looked the
man chrony.conf
and got following which sound promising and we don't need to that configuration of the guest-agent if that works as expected, how does podman machine handle time drift in mac?
Last I checked, they were using makestep
Just looked the
man chrony.conf
and got following which sound promising and we don't need to that configuration of the guest-agent if that works as expected, how does podman machine handle time drift in mac?Last I checked, they were using
makestep
The corresponding podman issue was https://github.com/containers/podman/issues/11541
@cfergeau: The following test failed, say /retest
to rerun all failed tests or /retest-required
to rerun all mandatory failed tests:
Test name | Commit | Details | Required | Rerun command |
---|---|---|---|---|
ci/prow/e2e-microshift | bdc3e5eeb305c67698d1440b0d22768acf5a8c26 | link | true | /test e2e-microshift |
Full PR test history. Your PR dashboard.
Created https://github.com/crc-org/snc/issues/916 one and we can have this PR in for time being.
/cherry-pick release-4.16
@praveenkumar: once the present PR merges, I will cherry-pick it on top of release-4.16 in a new PR and assign it to you.
/cherry-pick release-4.15
@praveenkumar: once the present PR merges, I will cherry-pick it on top of release-4.15 in a new PR and assign it to you.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: praveenkumar
The full list of commands accepted by this bot can be found here.
The pull request process is described here
@praveenkumar: new pull request created: #917
@praveenkumar: new pull request created: #918
On linux/windows, we don't setup the needed vsock devices, so qemu-guest-agent fails to start. We can use
ConditionVirtualization=apple
to only start it when running on a mac.