2

when I'm running 'ntpd -gq' from CentOS 5.10 (i686) the time is synced, but in CentOS 6.4 (x86_64) the command gets stuck (I need to stop it using ctl+c).

Any idea hoe to fix it?

EDIT: 

iptables -L -n -v
Chain INPUT (policy DROP 260 packets, 51849 bytes)

 pkts bytes target     prot opt in     out     source               destination

 1274 66464 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
 2111  168K ACCEPT     tcp  --  *      *       127.0.0.1            0.0.0.0/0           tcp dpt:8080
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:514
 1515  102K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
 8951 1352K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
 0     0    ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8
38599   11M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
1075K 1399M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 534K packets, 42M bytes)
 pkts bytes target     prot opt in     out     source               destination
MadHatter
  • 79,770
  • 20
  • 184
  • 232
User
  • 21
  • 2
  • How long have you waited before giving it `^C`? – MadHatter Apr 13 '14 at 08:21
  • 15 min (On CentOS 5 it usually takes few seconds). – User Apr 13 '14 at 08:30
  • What happens if instead you try `ntpdate name.of.preferred.ntp.server`? – MadHatter Apr 13 '14 at 08:36
  • If the ntpd is running I get: ntpdate[22248]: the NTP socket is in use, exiting. if ntps is stopped: ntpdate[22741]: no server suitable for synchronization found (but I get the same result on my 5.10 CentOS) – User Apr 13 '14 at 08:47
  • That sounds like either firewall or poor choice of ntp server. Can you try with my server, `ntpdate ntp.teaparty.net`, as I know that's up and sync'ed? – MadHatter Apr 13 '14 at 08:49
  • Same. But the 'ntpd -gq' command does work from my CentOS 32bit, so I find it hard to believe that a firewall related to this issue. – User Apr 13 '14 at 09:08
  • Clearly so, yes. Can you paste the output of `iptables -L -n -v` (on the C6 box) into your post? – MadHatter Apr 13 '14 at 09:14
  • OK, that should be allowing the UDP responses back in. You're confident about that 15 minutes, right - as in, your timed it with a watch, rather than just thinking "*it's been about a quarter of an hour*"? The man page for `ntpq` suggests it should take several minutes (6-10, in my experience), but not 15. – MadHatter Apr 13 '14 at 10:05
  • I measured the time again, I gave up after 25 min. – User Apr 13 '14 at 10:10
  • Fair enough. Do you have access to an external NTP source, so you can measure end-to-end connectivity? If not, do you have any interest in trying to do it with my server? We'd need to agree a time, and you'd need to tell me your external IP address. – MadHatter Apr 13 '14 at 10:47
  • 1
    Play with `--debug-level` and see if that gives useful information. Or try `strace`. – Martin Schröder Apr 17 '14 at 21:49
  • @MadHatter and Martin - Thanks for all this help. I have the same problem on the raspbian distribution on a raspberry pi 3. It has worked in the past, but is hanging now. No rules in iptables. And I note that unfortunately `/usr/sbin/ntpd: The 'debug-level' option has been disabled. -- this package was built using 'configure --disable--debug'` So I'm trying strace. I suspect `ntpq -p` and `ntpdc` are more helpful. They say I'm sending packets every 1024 seconds or so and getting no response, but `ntpdc> showpeer` does show me what the refid for the client is. Bizarre. – nealmcb Aug 10 '16 at 22:00
  • @nealmcb ummm, are you the original author of this question? If not, you'd be much better off asking a new question, telling us in more detail what you've tried so far, and making reference to this question to show you're aware of previous work on the subject. – MadHatter Aug 11 '16 at 05:06

0 Answers0