Time sync issues on silicon mac running Ubuntu 22 VM

B

BrianD12

Bit poster
I am running the latest version of Parallels on an M2 Max Mac Studio. I have two VMs running Ubuntu 22.04. The clock is being set 100+ years ahead on both of them. This happens when I just leave the VMs running, not paused or suspended. I set up a script to check the date every 5 seconds and it shows this:
Sun Dec 3 08:35:28 PM CST 2023
Sun Dec 3 08:35:33 PM CST 2023
... all fine until ....
Fri Dec 8 01:53:21 PM CST 2023
Fri Dec 8 01:53:26 PM CST 2023
Fri Dec 8 05:24:50 PM CST 2023
Sun Jan 29 12:52:18 PM CST 2119
Sun Jan 29 12:52:23 PM CST 2119

So it skipped ahead 4 hours and then 96 years. There was nothing going on with the VM, it was just running with no activity.

The hardware clock seems fine:
sudo hwclock -r
2023-12-09 10:29:41.569973-06:00
~ $ date
Sat Jan 28 10:23:07 AM CST 2119

I've tried with and without time sync from VM turned on, but I get the same behavior. I've tried ntp/chrony/timesyncd but once the time is off by that much, they can't get back in sync. The only way to get things back is to reboot. I even tried renaming prltimesync to prltimesync.stop to make sure that program wasn't causing it.

Trying to set the date manually looks like this:
sudo date --debug --set='2023-12-09 10:21:10'
date: parsed date part: (Y-M-D) 2023-12-09
date: parsed time part: 10:21:10
date: input timezone: system default
date: using specified time as starting value: '10:21:10'
date: starting date/time: '(Y-M-D) 2023-12-09 10:21:10'
date: '(Y-M-D) 2023-12-09 10:21:10' = 1702138870 epoch-seconds
date: timezone: system default
date: final: 1702138870.000000000 (epoch-seconds)
date: final: (Y-M-D) 2023-12-09 16:21:10 (UTC)
date: final: (Y-M-D) 2023-12-09 10:21:10 (UTC-06)
date: cannot set date: Invalid argument

Since that's obviously a valid date, my guess is it won't let you adjust the date that much in one command. Setting it back one day works:

date
Sun Jan 29 10:21:29 AM CST 2119
~ $ sudo date --set='2119-01-28 10:21:10'
Sat Jan 28 10:21:10 AM CST 2119
~ $ date
Sat Jan 28 10:21:11 AM CST 2119

I've been running on Parallels Intel for years with Ubuntu and never seen this so I have to think it's an ARM issue with Parallels.

Any ideas? At this point I'd be happy if I could just run a command to manually change the clock to the right time.

Thanks
Brian
 
BrianD12 said:
I am running the latest version of Parallels on an M2 Max Mac Studio. I have two VMs running Ubuntu 22.04. The clock is being set 100+ years ahead on both of them. This happens when I just leave the VMs running, not paused or suspended. I set up a script to check the date every 5 seconds and it shows this:
Sun Dec 3 08:35:28 PM CST 2023
Sun Dec 3 08:35:33 PM CST 2023
... all fine until ....
Fri Dec 8 01:53:21 PM CST 2023
Fri Dec 8 01:53:26 PM CST 2023
Fri Dec 8 05:24:50 PM CST 2023
Sun Jan 29 12:52:18 PM CST 2119
Sun Jan 29 12:52:23 PM CST 2119

So it skipped ahead 4 hours and then 96 years. There was nothing going on with the VM, it was just running with no activity.

The hardware clock seems fine:
sudo hwclock -r
2023-12-09 10:29:41.569973-06:00
~ $ date
Sat Jan 28 10:23:07 AM CST 2119

I've tried with and without time sync from VM turned on, but I get the same behavior. I've tried ntp/chrony/timesyncd but once the time is off by that much, they can't get back in sync. The only way to get things back is to reboot. I even tried renaming prltimesync to prltimesync.stop to make sure that program wasn't causing it.

Trying to set the date manually looks like this:
sudo date --debug --set='2023-12-09 10:21:10'
date: parsed date part: (Y-M-D) 2023-12-09
date: parsed time part: 10:21:10
date: input timezone: system default
date: using specified time as starting value: '10:21:10'
date: starting date/time: '(Y-M-D) 2023-12-09 10:21:10'
date: '(Y-M-D) 2023-12-09 10:21:10' = 1702138870 epoch-seconds
date: timezone: system default
date: final: 1702138870.000000000 (epoch-seconds)
date: final: (Y-M-D) 2023-12-09 16:21:10 (UTC)
date: final: (Y-M-D) 2023-12-09 10:21:10 (UTC-06)
date: cannot set date: Invalid argument

Since that's obviously a valid date, my guess is it won't let you adjust the date that much in one command. Setting it back one day works:

date
Sun Jan 29 10:21:29 AM CST 2119
~ $ sudo date --set='2119-01-28 10:21:10'
Sat Jan 28 10:21:10 AM CST 2119
~ $ date
Sat Jan 28 10:21:11 AM CST 2119

I've been running on Parallels Intel for years with Ubuntu and never seen this so I have to think it's an ARM issue with Parallels.

Any ideas? At this point I'd be happy if I could just run a command to manually change the clock to the right time.

Thanks
Brian
Click to expand...
Hello Brian,
We have sent you a private message. Kindly check your inbox.
Thank you!
 
I have seen the same issue three or four times in the last week.

I am doing some testing with three VMs running Alma Linux 9.2. So far, I have only seen the problem on one of the three where I am running a bunch of different commands. It's not happening consistently enough to know what command or commands are leading to the run away time issue.

I forgot to capture the full output from date today before I rebooted but the date was March 29, 2119.
 
I ended up re-creating all my VMs with a fresh install of Ubuntu 22. It was the same version as the ones that had the time sync problems, but after several weeks, I haven't seen the problem on the new VMs yet. They have all the same packages and I do the same things on them as before. It would be nice if Parallels could figure it out, but given that new VMs didn't show the problem for me, I suspect they will have trouble reproducing it.
 
Hi, sorry for replying on this old thread but I have the same problem as MatthewM31, 8-9 vms running on a Mac Mini M2 Pro, and randomly 1 of a 3 vm of a k3scluster shifts date to 2119, Debian 12 Bookworm vms installed from the same image
Thanks
 
Hi, I'm in touch with support, I opened a request. I'm trying to figure it out but at the moment I don't have a solution.
Anyway the problem is caused when the vm is under heavy load or stress, the ntp stops working as the time offset is too big
 
ok, my case it's a bit different: I have a vagrant box of Debian 12, builded by me with the Hashicorp Packer provider, the vms are created with Vagrant in linked clone configuration, so I don't have snapshots
 
Thanks, the post responds perfectly to the tests that the support ask me to perform, the activation of timesyncing with Macos, doesn't resolve the issue, my vms are completely isolated from host
 
I have the same issue. I'm using vagrant linked clone too. The logs indicate a kernel crash but it doesn't reboot. Date goes to 2119.
 
I started having this issue about 2 weeks ago on an Ubuntu VM in Parallels. Killing the prltimesync process after rebooting seems to be a work around.
I tested after a week of stable operation by rebooting, and letting prltimesync run. The date changed within 2 hours.

Note: I have already set Time to "Do Not Sync" in the settings for this VM.
 
AaronS25 said:
I started having this issue about 2 weeks ago on an Ubuntu VM in Parallels. Killing the prltimesync process after rebooting seems to be a work around.
I tested after a week of stable operation by rebooting, and letting prltimesync run. The date changed within 2 hours.

Note: I have already set Time to "Do Not Sync" in the settings for this VM.
Click to expand...
I assume `prltimesync` comes with Parallels Tools? Some of my VMs that experience this problem do no have Parallels Tools.
 
I had this daily, but since installing 20.1.0, it has disappeared. Has anyone else noticed a stability improvement?
 
That's so frustrating. My VM has parallels tools installed, but it was happening daily. Since upgrading, it's been almost a week without the issue. I think I upgraded to macOS 15.0.1 around the same time too. Are you all on the latest OS?
 
You must log in or register to reply here.
Back
Top