Stephen Hill's picture

So I've been eager to try tklbam for the past few years but have been unable to get it to work on our network.

I get the meesage:

> tklbam-backup

Amazon S3 and Duplicity need a UTC synchronized clock so we invoked the
following command::

ntpdate -u

Unfortunately, something went wrong...

3 Dec 16:12:59 ntpdate[4120]: no server suitable for synchronization found

It appears that the problem has to do with my office's access control list (firewall). Port 123 is open but I think the problem seems to stem from the fact that the request goes out to a "pool" of IP addresses and I can't predect where it's coming back from.... Possibly?

Does anyone know how I would open an ACL for this to work? Opening UDP port 123 is not fixing the problem.

Liraz Siri's picture

Duplicity relies on accurate time so syncing the clock is required. The hook that syncs time is in /etc/tklbam/hooks.d/fixclock.

I committed a fix to the hook error message so that it explains how to change to something else (e.g., the IP of a specific NTP server):

You can change the NTP server like this:

PS: sorry for the ridiculously late reply. This message fell between the cracks and I only came across it while searching for messages about TKLBAM hooks.
Andy's picture

There may be a possibility that the NTP server that you are trying to obtain time from is not correctly synchronized. I have seen this message a number of times when a GPS ntp server is first powered up and has not as yet synchronized to GPS but is being contacted by a NTP client to request time.


Ano Tisam's picture

Hi there,

Trying to do a tklbam-restore but keep running into NTP issue. I've tried

opening ports 123 on UDP in the firewall

and then running

  • export
  • service ntp stop
  • ntpdate
  • service ntp start

and then doing tklabam-restore but still no luck.

Anyone got a guide I can follow.






Jeremy Davis's picture

Actually TBH I thought that I posted a response to this thread early last week?! Obviously not... :(

Anyway, can you contact the NTP server? Is the time configured as either UTC, or UTC, but then with the locale offset? FWIW unlike Windows, TurnKey (and most Linux) have the clock set at UTC (and ideally the bios time set to UTC too). The real time where you are is then calculated using a locale. (reconfigure that using "dpkg-reconfigure tz-data").

Often on a server, I leave the system as UTC (I also set the BIOS clock to UTC if running on hardware). However, if you weren't aware of this config idiosyncrasy, you may change the clock to be your local time (but the server still thinks it's UTC). I'm not sure, but I recall from my Windows days, that if the local time and the remote NTP server time were too far out of whack, that it would not adjust the time, unless you explicitly forced it to. Maybe something similar is happening here?

So bottom line is that I'd be inclined to see what is going on with NTP. Make sure that your server is connecting to the remote NTP server ok and check that it is adjusting the time as it should be.

If you can ensure those factors but continue to have issues, then I'm not sure what it could be. Is your internet particularly slow? Perhaps there is too much latency between your server and the remote storage? ALthough TBH I doubt that would be it...

Ano Tisam's picture

Here's what I ended up doing

nano /etc/tklbam/hooks.d/fixclock

Change this line from this

command = "ntpdate -u " + NTPSERVER

To this (see details here)

command = "ntpdate-debian"

Then run

tklbam-restore [backupid]

I found that worked.

Hope that helps

Add new comment