1

On Arch Linux running as a guest OS on VMWare Fusion, I noticed the system time of Arch falls behind when I sleep the host OS and never gets back in sync. It appears systemd-timesyncd is loaded but inactive.

[root@arch1 ~]# systemctl status systemd-timesyncd
* systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled)
   Active: inactive (dead) since Tue 2014-09-30 11:04:42 PDT; 3min 7s ago
           start condition failed at Tue 2014-09-30 11:04:42 PDT; 3min 7s ago
           ConditionVirtualization=no was not met
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 17582 (code=exited, status=0/SUCCESS)
   Status: "Idle."

Update: The answers below explain how to get the systemd-timesyncd.service running under a VM, but it turns out that doesn't solve the time sync problem (which is probably why systemd-timesyncd is disabled under VMs). The Arch wiki page Installing Arch Linux in VMWare explains how to perform Time Synchronization between guest and host OS.

4

Just create a configuration file that unsets that parameter.

mkdir -p /etc/systemd/system/systemd-timesyncd.service.d
echo -e "[Unit]\nConditionVirtualization=" > /etc/systemd/system/systemd-timesyncd.service.d/allow_virt.conf
systemctl daemon-reload
systemctl start systemd-timesyncd.service

This technique is described in the systemd.unit man page:

Along with a unit file foo.service, a directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings to a unit, without having to modify their unit files. Make sure that the file that is included has the appropriate section headers before any directive.

  • +1 for not copying entire config – nponeccop Jan 16 '15 at 7:19
0

From systemd.unit man:

ConditionVirtualization= may be used to check whether the system is executed in a virtualized environment and optionally test whether it is a specific implementation. Takes either boolean value to check if being executed in any virtualized environment, or one of vm and container to test against a generic type of virtualization solution, or one of qemu, kvm, vmware, microsoft, oracle, xen, bochs, chroot, uml, openvz, lxc, lxc-libvirt, systemd-nspawn to test against a specific implementation. If multiple virtualization technologies are nested, only the innermost is considered. The test may be negated by prepending an exclamation mark.

ConditionVirtualization=no tells systemd to not run the service if the OS is being run in a virtualized environment. My guess is that check is there because some VMs provide guest OS tools that provide time synchronization. You can either install those tools on Arch or you can comment out the ConditionVirtualization=no in /usr/lib/systemd/system/systemd-timesyncd.service and then run the following commands:

systemctl daemon-reload
systemctl restart systemd-timesyncd

Now systemctl status systemd-timesyncd should show it's active:

[root@arch1 ~]# systemctl status systemd-timesyncd
* systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled)
   Active: active (running) since Tue 2014-09-30 11:10:12 PDT; 56s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 17648 (systemd-timesyn)
   Status: "Using Time Server 216.239.32.15:123 (time1.google.com)."
   CGroup: /system.slice/systemd-timesyncd.service
           `-17648 /usr/lib/systemd/systemd-timesyncd

Note, if you haven't done so already, you also need to setup /etc/systemd/timesyncd.conf to point at some ntp servers. For example:

# See timesyncd.conf(5) for details

[Time]
Servers=time1.google.com time2.google.com time3.google.com time4.google.com
  • Although this works, please copy ` /usr/lib/systemd/system/systemd-timesyncd.service` to ` /usr/lib/systemd/system/systemd-timesyncd-custom.service`, update the custom file, and start the custom service – eyoung100 Sep 30 '14 at 19:19
  • That's a good point since what I did could impact pacman updates. That said, if I create a custom timesync service, I'd also need to create custom services for anything that depends on systemd-timesyncd, which might be a bigger management pain than dealing with the modified file. – Doug Richardson Sep 30 '14 at 20:21
  • The choice is yours, I just brought up the issue... – eyoung100 Sep 30 '14 at 20:24
  • Please accept Davie's Answer, as he created a file for you that doesn't rewrite the original file. – eyoung100 Oct 1 '14 at 18:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.