There is a bug on Ubuntu 16.04 with systemd-timesyncd. Firstly the problem is because systemd-timesyncd.service has parameter that prevents starting it on OpenVZ (depending on man this should work without problems, but this is not true):


The solution for this part of problem is here: systemd-timesyncd.service inactive on Arch on VMWare. However, this still doesn't resolve problem at all because when trying to start it with ...

sudo systemctl start systemd-timesyncd

... results in something like this:

Aug 01 10:31:02 ingarill systemd[1]: systemd-timesyncd.service: Unit entered failed state.
Aug 01 10:31:02 ingarill systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'.
Aug 01 10:31:02 ingarill systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart.
Aug 01 10:31:02 ingarill systemd[1]: systemd-timesyncd.service: Start request repeated too quickly.

I copied this "error" part from https://www.reddit.com/r/linuxquestions/comments/4vln5o/cant_start_systemdtimesyncdservice/ where similar error is described (I don't think it is connected to this one at all). After that systemd-timesyncd state is inactive and last state is described as "Shutted down".

So that's what I discovered so far, hopefully enough for helping me resolve the problem. Thanks in advance!

  • 1
    what's the result from "sudo /usr/lib/systemd/systemd-timesyncd" ? – Michael D. Jan 9 '17 at 11:52
  • @MichaelD. there is no such executable, only folders boot, catalog, network, user and user-generators. – user1257255 Jan 13 '17 at 21:32

Works for me in virtualbox.

sudo mkdir /etc/systemd/system/systemd-timesyncd.service.d/

Then sudo -sWith sudo did the following not work.echo -e "[Unit]\nConditionVirtualization=yes" > /etc/systemd/system/systemd-timesyncd.service.d/enable-with-daemon.conf

Tell systemd to reload sudo systemctl daemon-reload

Then start the unit sudo systemctl start systemd-timesyncd

| improve this answer | |
  • Errors from systemctl status: condition failed -> ConditionVirtualization=!container was not met ... Failed to start Network Time Synchronization; Failed with result 'exit-code', Service has no hold-off time, scheduling restart; Stopped Network Time Synchronization; Start request repeated too quickly; Failed to start Network Time Synchronization ... I don't know what is wrong, is there anything to be installed along default packages which are installed as base, because this only fails on OpenVZ containers (at diff providers) meanwhile other KVM and VBox instances work without any problem. – user1257255 Jan 13 '17 at 21:38

I assume you're missing the executable. Q: what's the result from sudo /usr/lib/systemd/systemd-timesyncd A: There is no such executable, only folders boot, catalog, network, user and user-generators.

   cat /usr/lib/systemd/system/systemd-timesyncd.service

This service starts /usr/lib/systemd/systemd-timesyncd

file /usr/lib/systemd/systemd-timesyncd
/usr/lib/systemd/systemd-timesyncd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b64971999784b0c648889f282e346d8902e8c1a3, stripped

that is an executable

sudo pkgfile /usr/lib/systemd/systemd-timesyncd                                                                  

which comes with the systemd package.

The start should look like this:

sudo /usr/lib/systemd/systemd-timesyncd
Synchronized to time server (0.arch.pool.ntp.org).

Reinstall systemd package check for that executable. As long as you don't have it on your system the service will fail.

| improve this answer | |
  • Actually the file on my Ubuntu was located in /lib/systemd/, without the /usr/ directory. Basically all files were present as I figured out based on your answer and when I executed systemd-timesyncd I got error that I don't have enought permissions - capatibilities to run such task. Seems like I'm unable to set time because of OpenVZ virtualization. Thanks for your time and help! – user1257255 Jan 19 '17 at 8:41

The problem in this case is usage of OpenVZ and permissions that are set on containers. If your provider enabled you sys_time permission then you can set time of VPS as you want, in other case you don't have enough permissions/capatibilities to change it and should sync by the main machine where OpenVZ is configured.

As I read the time in this case (if you don't have sys_time capatibility) can only be set by VPS provider on their main OpenVZ machine and is synced to all nodes.

| improve this answer | |

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.