Tag Info

Hot answers tagged

9

.INIT. 16 u That's not fine. You either queried the state to soon, or your ntpd can't connect to those servers at all. When it is synced, it should display IP addresses or host names in the refid column, and values like 2 or 3 in the st column. The output of a working ntpd should look like this: iserv ~ # ntpq -p remote ...


9

date +%s%N will give the nano seconds since epoch To get the micro seconds just do an eval expr `date +%s%N` / 1000


8

There's no much point asking for this kind of precision in a shell script, given that running any command (even the date command) will take at least a few hundreds of those microseconds. In particular, you can't really use the date command to time the execution of a command with this kind of precision. For that, best would be to use the time command or ...


6

It appears that NTP is to far out of sync (1391656797.298671) and needs a forced sync. When using the -d option in ntpdate, it's just debugging. It goes through all the steps but doesn't actually force a sync. Do one of the following: 'ntpd -q' or 'ntpdate -buv ntp.ubuntu.com'


6

Separate out the problem: is it a Timezone misconfiguration, or a time configuration? You can use a couple of tools, date and zdump to determine this. If date reports the correct UTC time, then you know the problem exists in the timezone setting, rather than in the internal time setting. $ date --utc Fri Jun 28 14:02:43 UTC 2013 $ date Fri Jun 28 10:02:45 ...


6

$ ntpdate -q pool.ntp.org server 86.59.113.118, stratum 2, offset 0.007942, delay 0.07298 server 147.251.48.140, stratum 2, offset -0.001173, delay 0.05101 server 212.18.3.19, stratum 2, offset -0.003886, delay 0.04689


6

ntp intentionally slews the system time towards the time provided by its peers in very small increments, to avoid large jumps in time that might upset running processes. Although accurate time keeping is essential for host-to-host communication, even more important is the integrity of the system's own clock. There are some useful and interesting FAQs about ...


6

Try running it as: ntpdate -u 0.pool.ntp.org The -u configures ntpdate to use an unprivileged port, which it always does when you use the -d option. Therefore, it it works with -u and -d but not without either, I'd double check your firewalls. From the man page: -u Direct ntpdate to use an unprivileged port for outgoing packets. This is most useful ...


4

I've seen syslog entries like that on a Slackware machine a few years ago. I believe I bought the machine in question in 2002, and pretty much ran it 24/7 for years: it was my SSH, SMTP and HTTP server. The NTP failures came on slowly, and gradually increased in frequency. I fixed it the first time by changing the "CMOS RAM" battery, which was one of ...


4

It looks like you have the Busybox version of ntpd. Here's a useful HOWTO: http://wiki.openwrt.org/doc/howto/ntp.client For example: ntpd -q -p ptbtime1.ptb.de


4

As with most things in Arch, there isn't a default time management tool set up; you can choose between several time synchronisation options. Give the RaspberryPi's lack of a RTC, I would suggest that you ensure that you use a tool that can store the last time to disk and then references that at boot time to pull the clock out of the dawn of UNIX time. ...


4

For this answer, I'll assume that there may be several elements working hard to set your time straight. Since I don't really want to wild-guess about which one is working against you, I'll try and give you an answer which should help you find it yourself instead. On a UNIX system, the clock can typically be set using the stime system call. As things ...


4

As you said date +%s returns the number of seconds since the epoch. So, date +%s%N returns the seconds and the current nanoseconds. Dividing date +%s%N the value by 1000 will give in microseconds.i.e echo $(($(date +%s%N)/1000))


3

What you're looking for is ntpd with the --panicgate option. The panicgate option allows the first adjustment after ntpd starts to be any size. This is exactly for the use case you described where a machine comes up and it's clock is wildly inaccurate. When ntpd starts with this option enabled, it can take a moment for it find a server and establish ...


3

With ntpdate: ntpdate -d 0.debian.pool.ntp.org Or for the offset only: ntpdate -d 0.debian.pool.ntp.org | sed -n '$s/.*offset //p'


3

I'm not sure why you would like to request the time from a NTP server if you want to get the current local time set on your server. To do it, simply use the date command. EDIT: but if you still want to retrieve the time from a NTP server, you can use the ntpdate command followed by the NTP server's IP address.


3

Try: dpkg-reconfigure tzdata That should allow to set the timezone for the system (make a copy of the selected timezone file onto /etc/timezone). More generally, it can be difficult to figure out which package you need to configure to change a setting as it's not always obvious. Things that can help: If you know the configure file where that setting is ...


3

A computer with two or more network cards, unless it is specifically configured as a router or NAT gateway or something, will not automatically provide access to network A from computers on network B. However, a program (such as ntpd) running on your computer can talk to both networks. Each network interface on your computer will have its own IP address. ...


3

Debian expects you to install ntp yourself if you want your clock synchronized. Pretty much all you should have to do is apt-get install ntp. The default install, without any tasks, is fairly minimal. I believe the GNOME desktop task, at least, will install it by default (as well as many other packages). Not sure if the other desktops will as well. There ...


3

How many peers are you using? If you use three (or more) servers, then NTP has the intelligence to tell if one is out of sync with the others and it will stop using it until it becomes "sane" again. I would suggest choosing servers from here: http://www.pool.ntp.org/en/ There's probably nothing you can do about a server misbehaving if you don't control ...


3

Something like the following should work. restrict default ignore restrict 127.0.0.1 nomodify restrict 192.168.2.102 mask 255.255.255.0 nomodify notrap noquery server 192.168.2.102 burst iburst server 127.127.1.0 fudge 127.127.1.0 stratum 10


3

I did get it working, so for posterity, someone on #ntp (freenode) said machine A may not be happy if B does not report itself as synced. This can be observed with ntpq -p on B not showing any servers prefixed with an asterisk. Fudging a local source on B (which actually does sync, by examination of the system clock) corrected that: server 127.127.1.0 ...


2

[a very late answer, but added for others that might follow] limiting which interfaces you run ntpdate for might be useful, but it sounds like your major problem is lack of functioning realtime clock hardware, hence the huge initial offset. I suggest you look into the fake_hwclock package. From the package description: Package: fake-hwclock (0.5) ...


2

I found the solution on this website. NTPdate was trying to update the date each time an interface went up, which in my case was three times during the boot process. So I modified /etc/network/if-up.d/ntpdate to only run ntpdate if eth0 goes up by adding the following to the top of the script: # Only update the date if eth0 goes up. if [ "$IFACE" != eth0 ]; ...


2

Run ntpd on all machines. Set the server so that it gets its time from the gps receiver and point the other machines to the server. With iburst the clients will sync fast enough for your purposes.


2

ntp writes to the system log file (could be either daemon.log or syslog.log) any error or warning message. It could be changed in the configuration file ntp.conf using the logfile /path/to/file.log or the -l switch while starting.


2

You should add the Capability option "sys_time" as stated in [Users] How does the clock work in OpenVZ? via the command: vzctl set 101 --capability sys_time:on --save You should of course replace "101" by the CTID of your container. Then reboot the machine/container. Now, ntpd should run as expected with the "ntp" user. You can then check that the ntpd ...


2

The offset is way too large; make sure to synchronise the clock “one-shot” before you start xntpd, e.g. with rdate (sudo rdate -nv 2.pool.ntp.org) or xntpd’s very own ntptime utility.


2

Easy way: # rm /etc/dhcp/dhclient-exit-hooks.d/ntp


2

If none of the NTP servers you're trying seem to be responding, it's likely that a firewall is blocking either outgoing requests or incoming responses. NTP uses UDP port 123. You can check whether outgoing requests are being blocked by running traceroute on that port. Depending on your implementation of traceroute, this may be something like traceroute -p ...



Only top voted, non community-wiki answers of a minimum length are eligible