OS X, podman machine time stops sometime

[dm3ch]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description
Date output is wrong for both containers and podman machine itself on OS X.

Steps to reproduce the issue:
I'm not sure 100% in my reproduction guide

1. Install podman on OSX
2. Create podman machine
3. Wait couple of days
4. Get date from podman machine

Describe the results you received:
OS X date:

$ date
Sun Sep 12 15:55:30 MSK 202

Podman container and podman machine ssh date:

$ date
Fri Sep 10 19:47:08 UTC 2021

I have ran same command again and time was completely the same.
After stoping and starting machine again time started to go.

Describe the results you expected:
Date inside podman machine should be right

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

Client:
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.17
Built:        Mon Aug 30 22:15:26 2021
OS/Arch:      darwin/amd64

Server:
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.16.6
Built:        Mon Aug 30 23:46:36 2021
OS/Arch:      linux/amd64

OS X info:

[afbjorklund]

I think KVM does this (ntp) in "hardware", but it seems to be missing from HVF ?

Might have to run an ntpd in the VM, before it is supported by the virtualization

EDIT: I think I got RTC and NTP confused in my head there.

[    0.249404] PM: RTC time: 17:44:05, date: 2021-09-13
[    0.769992] rtc_cmos 00:00: RTC can wake from S4
[    0.773422] rtc_cmos 00:00: registered as rtc0
[    0.774279] rtc_cmos 00:00: setting system clock to 2021-09-13T17:44:06 UTC (1631555046)
[    0.775629] rtc_cmos 00:00: alarms up to one day, y3k, 114 bytes nvram, hpet irqs

[guillaumerose]

There is a long blog post about this on the Docker blog.
https://www.docker.com/blog/addressing-time-drift-in-docker-desktop-for-mac/

Docker Desktop runs an embedded NTP server on the host. It takes his source on the system time. A NTP client in the VM keeps it in sync.

[dm3ch]

JFYI: Maybe my case is connected with that, but in my case it wasn't a slowdown because time completely stoped.

But it looks like NTP hack could workaround this particular issue too

[rhatdan]

@dustymabe Is this something we should turn on in Fedora CoreOS?

[rhatdan]

@ashley-cui PTAL

[dustymabe]

hmm.. NTP should be utilized on Fedora CoreOS by default

What's the output of the following commands run on the Fedora CoreOS host?

• timedatectl
• systemctl status chronyd
• sudo journalctl -b 0 -u chronyd

[afbjorklund]

My "podman machine" CoreOS seems synced to 2.fedora.pool.ntp.org

[guillaumerose]

I think podman machine should be self-contained and not require an Internet access. What if you code in the plane? The time should not drift.

[guillaumerose]

This situation can also happen after suspend/resume of the system. See a solution here: https://github.com/linuxkit/linuxkit/tree/master/pkg/host-timesync-daemon

[github-actions]

A friendly reminder that this issue had no activity for 30 days.