[SOLVED] ntpd not synchronized

rbeserie · 03-29-2011, 02:38 AM

Hi all,

I am having a situation with an NTPD server.

Code:

    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 plesk2.datacent .INIT.          16 u    -   64    0    0.000    0.000   0.000
 91.198.87.118.b .INIT.          16 u    -   64    0    0.000    0.000   0.000
 core.fr.zeroloo .INIT.          16 u    -   64    0    0.000    0.000   0.000
 178-26-105-100- .INIT.          16 u    -   64    0    0.000    0.000   0.000

and it remains so no matter how long I wait...

Hoping to get better results with ntpdate, I stopped NTPS and tried :

Code:

# ntpdate ntp.skynet.be
29 Mar 09:12:26 ntpdate[4715]: no server suitable for synchronization found

# ntpdate -ud ntp.skynet.be
29 Mar 09:14:02 ntpdate[4814]: ntpdate 4.2.4p4@1.1520-o Sun Nov 22 16:14:35 UTC 2009 (1)
transmit(195.13.23.5)
receive(195.13.23.5)
transmit(195.13.23.5)
receive(195.13.23.5)
transmit(195.13.23.5)
receive(195.13.23.5)
transmit(195.13.23.5)
receive(195.13.23.5)
transmit(195.13.23.5)
server 195.13.23.5, port 123
stratum 2, precision -20, leap 00, trust 000
refid [195.13.23.5], delay 0.04407, dispersion 0.00085
transmitted 4, in filter 4
reference time:    d13c02f2.9bdfb0d5  Tue, Mar 29 2011  9:04:18.608
originate timestamp: d13c053b.f2e924f2  Tue, Mar 29 2011  9:14:03.948
transmit timestamp:  d13c053a.a1f7403d  Tue, Mar 29 2011  9:14:02.632
filter delay:  0.04626  0.04575  0.04768  0.04407 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 1.307964 1.307767 1.308700 1.306952
         0.000000 0.000000 0.000000 0.000000
delay 0.04407, dispersion 0.00085
offset 1.306952

29 Mar 09:14:02 ntpdate[4814]: step time server 195.13.23.5 offset 1.306952 sec

I am running Debian Lenny 64b, and every packages are totally updated.

I have 25 identical servers. And there is just one giving me this problem. From what I see, it is not a connection/FW issue since ntpdate get replies from the ntp server (ntp.skynet.be is my isp's stratum 2 ntp server)

any ideas to get me back on track ?

rbeserie · 03-29-2011, 07:24 AM

Right...

I am making progresses (kind of), using ntpdate on unprivileged ports ( -u flag) works to sync the date once.

Now, what does use an unprivileged port means.
and how can I tell ntpd to use unprivileged ports ?

kbp · 03-29-2011, 07:28 AM

Can you show us the content of /etc/ntp.conf ?

<edit>your second post indicates that you may be firewalled</edit>

tronayne · 03-29-2011, 08:01 AM

If you take a look at /etc/services; e.g.,

Code:

grep -w ntp /etc/services

you ought to see something similar to

Code:

                           
ntp             123/tcp    #Network Time Protocol                                                        
ntp             123/udp    #Network Time Protocol

Them's the ports -- make sure they're not blocked (in a router, IPTABLES, etc.). They should not be unless somebody tuned 'em off (NTPD typically "just works" through routers and the like).

You're probably aware that NTPD will not synchronize if the local clock is too far off (thus using ntpdate to get it on-time once before starting NTPD). There is a possibility that your CMOS battery is dead (if the box is more than a couple of years old that can happen). If the battery is dead and the box has been turned off for some period of time (a few days or a week), the clock will have more-or-less stopped and you'll need to synchronize it once with ntpdate and then it should synchronize and stay that way as long as the box is powered on with NTPD.

From you post is look as though you're using pool time servers (three are more than enough). The advantage of using pool servers is that, every so often, a server will go down, communications will be bad or some other thing will crop up and NTPD will automagically evaluate the remaining pool servers and pick the one that's best and synchronize to it -- your ISPs server must be reachable (can you ping it? Is the response time reasonable -- that would be less than any pool server?).

In my ntp.conf file I use these server settigns

Code:

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10
#server  pool.ntp.org
server  0.us.pool.ntp.org
server  1.us.pool.ntp.org
server  2.us.pool.ntp.org

You want the "local clock" entry to be there (for fall-back when the intra- or internet goes away) and I specify three pool servers to be in the US (wherever you are physically you want to use the country code to limit your possible choices to time servers as electrically close to you as you can -- ping comes in handy for this).

Something else you may want to do is, in the NTPD start-up file, there should be a section that looks like this (that I've modified to add logging). Might helps to see what's going on.

Code:

# Start ntpd:
ntpd_start() {
  # Clear the log file
  >/tmp/ntp.log
  CMDLINE="/usr/sbin/ntpd -g"
  echo -n "Starting NTP daemon:  $CMDLINE"
  $CMDLINE -p /var/run/ntpd.pid -l /tmp/ntp.log
  echo
}

Anyway, check the battery, ping a few things and take a look at your /etc/ntp.conf file.

Hope this helps some.

rbeserie · 03-29-2011, 09:28 AM

Here is my /etc/ntp.conf

Code:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.europe.pool.ntp.org iburst dynamic
server 1.europe.pool.ntp.org iburst dynamic
server 2.europe.pool.ntp.org iburst dynamic
server 3.europe.pool.ntp.org iburst dynamic


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

It basically is the default setup from the Debian package. I just changed the ntp pool to use.

Since ntpdate isn't working either, I did set the WH clock and the system clock manually. From what my human eye can see, there is less then a second difference between a synced servers ans this one.

I would be verry suprised if the RTC battery was dead, it's a brand new box. but, hey... checking dosn't cost a thing... A shall do that ASAP.

I tried pinging my ISP ntp server but it doesn't reply to my pings. I tried from another place where I have no problem to get ntp synced, but it doesn't reply either. I guess they are bloking ICMP packets.

Thanks for the local clock tip, I'll remember to set it in my config file.

tronayne · 03-29-2011, 10:07 AM

Uh, let's grasp at straws for a minute -- brand new box? OK, the battery is most likely to be fine.

One thing to take a look at is the content of /var/lib/ntp/ntp.drift. There should be a number in it. If there is not, as root put one in like this

Code:

echo 0 > /var/lib/ntp/ntp.drift

Back in the pre-history of the world, you had to do this manually for NTPD to synchronize with time servers -- nowadays maybe, maybe not, but there does have to be a number in that file for NPTD to work.

One more thing to take a look at is how many NTP daemons you may have running; I know, you stopped the daemon before you did anything and then restarted it but, you know, just for drill

Code:

ps -ef | grep ntp

should show only

Code:

root      1778     1  0 Mar24 ?        00:00:09 /usr/sbin/ntpd -g -p /var/run/ntpd.pid -l /tmp/ntp.log
trona    14313 14298  0 10:53 pts/1    00:00:00 grep ntp

(The second line is me grepping for npt). Your path names may vary (and you won't have the -l /tmp/ntp.log unless you turned on logging).

Got more than one? Execute your NTPD startup command with "stop" instead of "start" then start killing any additional PIDs (as root, kill -9 PID where "PID" is, above, 1778).

Looking at your ntp.conf file, it seems just a little over complicated or perhaps a little too busy. NTPD tends to work just fine both with and without a lot of extra configuration stuff and, under the rule of simpler-is-better (or less-is-more), maybe give something like this a try:

Code:

# Undisciplined Local Clock.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10
# Pool servers
server  0.europe.pool.ntp.org
server  1.europe.pool.ntp.org
server  2.europe.pool.ntp.org

#
# Drift file.
driftfile /var/lib/ntp/ntp.drift
multicastclient
broadcastdelay  0.008                                                            
                                                                                                         
# Don't serve time or stats to anyone else by default (more secure)                                      
restrict default noquery nomodify                                                                        
# Trust ourselves.  :-)                                                                                  
restrict 127.0.0.1

That's all you really need (you can add the statistics stuff if want or need them after you get the thing working).

If you turn on logging, this is typically what the log file file will look like:

Code:

cat /tmp/ntp.log                                                                
24 Mar 13:57:38 ntpd[1778]: proto: precision = 0.135 usec
24 Mar 13:57:38 ntpd[1778]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
24 Mar 13:57:38 ntpd[1778]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
24 Mar 13:57:38 ntpd[1778]: Listen and drop on 1 v6wildcard :: UDP 123
24 Mar 13:57:38 ntpd[1778]: Listen normally on 2 lo 127.0.0.1 UDP 123
24 Mar 13:57:38 ntpd[1778]: Listen normally on 3 eth0 192.168.1.10 UDP 123
24 Mar 13:57:38 ntpd[1778]: Listen normally on 4 lo ::1 UDP 123
24 Mar 13:57:51 ntpd[1778]: Listen normally on 5 eth0 fe80::210:18ff:fe8a:82c1 UDP 123
24 Mar 13:57:51 ntpd[1778]: new interface(s) found: waking up resolver

And this is what ntpq -p will look like

Code:

/usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l  35h   64    0    0.000    0.000   0.000
+ntp2.Housing.Be 128.32.206.54    2 u  339 1024  377  1154.03   -3.683  54.995
*private.ssl119. .CDMA.           1 u  983 1024  377  1325.11  -94.126 149.048
+name1.glorb.com 128.252.19.1     2 u  855 1024  377  1314.61   47.529  90.440

Hope this helps some.

rbeserie · 03-29-2011, 10:38 AM

Grrr...

Code:

# cat /var/lib/ntp/ntp.drift
0.000

/var/lib/ntp/ntp.drift --> Good.

Code:

# ps -ef | grep ntp
ntp      20102     1  0 16:07 ?        00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 106:110 -g -l /var/log/ntp.log
root     28680 28555  0 17:27 pts/0    00:00:00 grep ntp

ps --> Good. (I did activate logging but there isn't much in it)

my log file:

Code:

29 Mar 17:30:54 ntpd[28909]: logging to file /var/log/ntp.log
29 Mar 17:30:54 ntpd[28909]: precision = 1.000 usec
29 Mar 17:30:54 ntpd[28909]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #1 wildcard, ::#123 Disabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #2 lo, ::1#123 Enabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #3 eth0, fe80::1ec1:deff:fe70:70c4#123 Enabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #4 eth2, fe80::20a:cdff:fe1a:616a#123 Enabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #5 eth1, fe80::1ec1:deff:fe70:70c6#123 Enabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #6 lo, 127.0.0.1#123 Enabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #7 eth2, 10.1.254.200#123 Enabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #8 eth0, 192.168.254.251#123 Enabled
29 Mar 17:30:54 ntpd[28909]: Listening on interface #9 eth1, 192.168.123.155#123 Enabled
29 Mar 17:30:54 ntpd[28909]: kernel time sync status 0040
29 Mar 17:30:55 ntpd[28909]: frequency initialized 0.000 PPM from /var/lib/ntp/ntp.drift

I did simplify my config file as you suggested, and restarted ntpd.
and here is the result...

Code:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.          10 l   20   64   37    0.000    0.000   0.001
 manage.mediainv .INIT.          16 u    -   64    0    0.000    0.000   0.000
 ns2.puck.ch     .INIT.          16 u    -   64    0    0.000    0.000   0.000
 mail.deployis.e .INIT.          16 u    -   64    0    0.000    0.000   0.000

tronayne · 03-29-2011, 11:07 AM

That looks like it should sync -- if you've waited a while (up to 10 minutes or so) and execute ntpq -p do you see something more-or-less like the above?

I'm kind of running out of ideas -- the nuclear option is to reboot, might want to try that.

kbp · 03-29-2011, 05:14 PM

Quote:

NTPD will not synchronize if the local clock is too far off

@tronayne: I thought that was what /etc/ntp/step-tickers was for ... no ?

kbp · 03-29-2011, 05:48 PM

Just to check that there's no firewall blocking access, please run this from the ntp client :-

Code:

nmap -sU -PN -p 123 <ntp_server_ip>

cheers

rbeserie · 03-30-2011, 02:10 AM

After a night waiting, ntpq -p gives exactly the damn same thing.

Code:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.          10 l   25   64  377    0.000    0.000   0.001
 manage.mediainv .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 ns2.puck.ch     .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 mail.deployis.e .INIT.          16 u    - 1024    0    0.000    0.000   0.000

I double checked the HW clock and the System clock again, they are less then 1 sec away from another synchronized server. Even if a huge offset would prevent ntpd from changing the local server clock, it shouldn't prevent it from getting time info from remote ntp servers (cf. ntpq -p witch only shows 0s), right ?

Code:

#nmap -sU -PN -p 123 ntp.skynet.be

Starting Nmap 4.62 ( http://nmap.org ) at 2011-03-30 09:08 CEST
Interesting ports on ntp1.belbone.be (195.13.23.5):
PORT    STATE         SERVICE
123/udp open|filtered ntp

Nmap done: 1 IP address (1 host up) scanned in 2.160 seconds

Is that good doctor?

iptables rules :

Code:

$IPT -A INPUT -i eth1 -p udp --dport 123 -s 192.168.123.0/24 -j ACCEPT
$IPT -A OUTPUT -o eth0 -p udp --dport 123 -j ACCEPT

My isp router is configured to forward everything (every ports / every protocols) to my server.
(I already asked them to check the router config, they assured me it was identical to another place where sync works)

To make sure....

Code:

reboot ## And I don't like that !!! 
...
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.          10 l   25   64  377    0.000    0.000   0.001
 manage.mediainv .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 ns2.puck.ch     .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 mail.deployis.e .INIT.          16 u    - 1024    0    0.000    0.000   0.000

AAAAAAAAAAAAAAAAAA...... Bouhouhou ....

tronayne · 03-30-2011, 05:14 AM

Hi, sorry you're having so much trouble.

I got to looking at your log and noticed what looks like multiple Ethernet ports? It's reporting three (eth0, eth1 and eth2)? I don't really know if that has anything to do with this (and I'll dig a little and see what I can find out). What does ifconfig tell you? You ought to see something similar to

Code:

fubar-root-/root: ifconfig
eth0      Link encap:Ethernet  HWaddr 00:10:18:8a:82:c1  
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::210:18ff:fe8a:82c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:339484 errors:0 dropped:0 overruns:0 frame:0
          TX packets:268825 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:292706782 (279.1 MiB)  TX bytes:28351128 (27.0 MiB)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:249916 errors:0 dropped:0 overruns:0 frame:0
          TX packets:249916 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1380282617 (1.2 GiB)  TX bytes:1380282617 (1.2 GiB)

Too, I used ping on the three servers listed in you last post and I can see all three:

Code:

fubar-root-/root: ping -c 5 manage.mediainv
PING manage.mediainv.com (209.62.20.227) 56(84) bytes of data.
64 bytes from ev1s-209-62-20-227.theplanet.com (209.62.20.227): icmp_req=1 ttl=44 time=1146 ms
64 bytes from ev1s-209-62-20-227.theplanet.com (209.62.20.227): icmp_req=2 ttl=44 time=1374 ms
64 bytes from ev1s-209-62-20-227.theplanet.com (209.62.20.227): icmp_req=3 ttl=44 time=1502 ms
64 bytes from ev1s-209-62-20-227.theplanet.com (209.62.20.227): icmp_req=4 ttl=44 time=1626 ms
64 bytes from ev1s-209-62-20-227.theplanet.com (209.62.20.227): icmp_req=5 ttl=44 time=1549 ms

--- manage.mediainv.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4222ms
rtt min/avg/max/mdev = 1146.727/1440.123/1626.929/168.127 ms, pipe 2

fubar-root-/root: ping -c 5 ns2.puck.ch
PING ns2.puck.ch (153.109.180.3) 56(84) bytes of data.
64 bytes from ns2.puck.ch (153.109.180.3): icmp_req=1 ttl=42 time=1010 ms
64 bytes from ns2.puck.ch (153.109.180.3): icmp_req=2 ttl=42 time=1257 ms
64 bytes from ns2.puck.ch (153.109.180.3): icmp_req=3 ttl=42 time=1503 ms
64 bytes from ns2.puck.ch (153.109.180.3): icmp_req=4 ttl=42 time=1289 ms
64 bytes from ns2.puck.ch (153.109.180.3): icmp_req=5 ttl=42 time=1434 ms

--- ns2.puck.ch ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4356ms
rtt min/avg/max/mdev = 1010.728/1299.417/1503.714/170.431 ms, pipe 2

fubar-root-/root: ping -c 5 mail.deployis.eu
PING mail.deployis.eu (217.20.135.253) 56(84) bytes of data.
64 bytes from mail.deployis.eu (217.20.135.253): icmp_req=1 ttl=41 time=1281 ms
64 bytes from mail.deployis.eu (217.20.135.253): icmp_req=2 ttl=41 time=1423 ms
64 bytes from mail.deployis.eu (217.20.135.253): icmp_req=3 ttl=41 time=1457 ms
64 bytes from mail.deployis.eu (217.20.135.253): icmp_req=4 ttl=41 time=1423 ms
64 bytes from mail.deployis.eu (217.20.135.253): icmp_req=5 ttl=41 time=1584 ms

--- mail.deployis.eu ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4414ms
rtt min/avg/max/mdev = 1281.710/1434.338/1584.839/96.676 ms, pipe 2

I'm guessing that the last part of the address of the third sever is "eu."

You should be able to ping all three (and you should get significantly less transit times -- I'm sitting in northeaster Michigan in the US on a satellite dish, not the fastest turnaround times).

Also, I wounder about the "filtered" in your nmap display? Using the server I'm synchronized to,

Code:

fubar-root-/root: nmap -sU -PN -p 123 ntp.your.org

Starting Nmap 5.21 ( http://nmap.org ) at 2011-03-30 05:59 EDT
Nmap scan report for ntp.your.org (204.9.54.119)
Host is up (1.8s latency).
PORT    STATE SERVICE
123/udp open  ntp

Nmap done: 1 IP address (1 host up) scanned in 3.63 seconds

Have you considered deleting the IPTABLES rules (just for testing)? I'm no IPTABLES expert (in fact, I don't even qualify as a novice and can barely spell it correctly) but it looks odd.

And, have you looked at /etc/services and do you see this

Code:

fubar-root-/root: grep -w ntp /etc/services  
ntp             123/tcp    #Network Time Protocol
ntp             123/udp    #Network Time Protocol

Just trying to cover all the bases.

[EDIT]
Looking at the NTP Debugging Techniques page of the documentation (on my system located at file:///usr/doc/ntp-4.2.6p1/html/debug.html, yours may vary), I noted

Quote:

Some problems are immediately apparent when the daemon first starts running. The most common of these are the lack of a UDP port for NTP (123) in the Unix /etc/services file (or equivalent in some systems). Note that NTP does not use TCP in any form. Also note that NTP requires port 123 for both source and destination ports. These facts should be pointed out to firewall administrators.

Other problems are apparent in the system log, which ordinarily shows the startup banner, some cryptic initialization data and the computed precision value. Event messages at startup and during regular operation are sent to the optional protostats monitor file, as described on the Event Messages and Status Words page. These and other error messages are sent to the system log, as described on the ntpd System Log Messages page. In real emergencies the daemon will sent a terminal error message to the system log and then cease operation.

The next most common problem is incorrect DNS names. Check that each DNS name used in the configuration file exists and that the address responds to the Unix ping command. The Unix traceroute or Windows tracert utility can be used to verify a partial or complete path exists. Most problems reported to the NTP newsgroup are not NTP problems, but problems with the network or firewall configuration.

[/EDIT]
Might be worth a look-see...

tronayne · 03-30-2011, 05:54 AM

Quote:

Originally Posted by kbp

@tronayne: I thought that was what /etc/ntp/step-tickers was for ... no ?

Yeah, but...

Quote:

Unless using the iburst option, the client normally takes a few minutes to synchronize to a server. If the client time at startup happens to be more than 1000 s distant from NTP time, the daemon exits with a message to the system log directing the operator to manually set the time within 1000 s and restart. If the time is less than 1000 s but more than 128 s distant, a step correction occurs and the daemon restarts automatically.

When started for the first time and a frequency file is not present, the daemon enters a special mode in order to calibrate the frequency. This takes 900 s during which the time is not disciplined. When calibration is complete, the daemon creates the frequency file and enters normal mode to amortize whatever residual offset remains.

Not the case here (the OP had set the time manually to pretty-darn-close).

michaelk · 03-30-2011, 07:17 AM

As I understand the process step-tickers is used by ntpdate to initially set the clock. However, the same function is accomplished with ntp's -g flag.

rbeserie · 03-30-2011, 07:39 AM

Mmmm, I too noticed the duplicated line in the log file, but I did not look frther into that since my other servers (Identical HW) gives me the same messages when ntpd starts.

My ifconfig file looks ok to me. nothing fancy, no aliases, plain fixed ipaddress in ipV4.

Code:

# ifconfig 
eth0      Link encap:Ethernet  HWaddr 1c:c1:de:70:70:c4  
          inet addr:192.168.254.251  Bcast:192.168.254.255  Mask:255.255.255.240
          inet6 addr: fe80::1ec1:deff:fe70:70c4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7119 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7040 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:936074 (914.1 KiB)  TX bytes:1618611 (1.5 MiB)
          Interrupt:31 Memory:f8000000-f8012100 

eth1      Link encap:Ethernet  HWaddr 1c:c1:de:70:70:c6  
          inet addr:192.168.123.155  Bcast:192.168.123.255  Mask:255.255.255.0
          inet6 addr: fe80::1ec1:deff:fe70:70c6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:109027 errors:0 dropped:0 overruns:0 frame:0
          TX packets:90640 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8334479 (7.9 MiB)  TX bytes:9295014 (8.8 MiB)
          Interrupt:39 Memory:f6000000-f6012100 

eth2      Link encap:Ethernet  HWaddr 00:0a:cd:1a:61:6a  
          inet addr:10.1.254.200  Bcast:10.1.254.255  Mask:255.255.255.0
          inet6 addr: fe80::20a:cdff:fe1a:616a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:468 (468.0 B)
          Interrupt:245 Base address:0xe000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:16681 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16681 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1556107 (1.4 MiB)  TX bytes:1556107 (1.4 MiB)

I too can ping the 3 ntp server i'm trying to sync with. (and yes I got mutch shorter delays)

Code:

 # ping mail.deployis.eu
PING mail.deployis.eu (217.20.135.253) 56(84) bytes of data.
64 bytes from mail.deployis.eu (217.20.135.253): icmp_seq=1 ttl=50 time=48.0 ms
64 bytes from mail.deployis.eu (217.20.135.253): icmp_seq=2 ttl=50 time=50.5 ms
^C
--- mail.deployis.eu ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 48.079/49.302/50.526/1.243 ms

# ping ns2.puck.ch
PING ns2.puck.ch (153.109.180.3) 56(84) bytes of data.
64 bytes from ns2.puck.ch (153.109.180.3): icmp_seq=1 ttl=47 time=39.1 ms
64 bytes from ns2.puck.ch (153.109.180.3): icmp_seq=2 ttl=47 time=37.6 ms
64 bytes from ns2.puck.ch (153.109.180.3): icmp_seq=3 ttl=47 time=40.0 ms
^C
--- ns2.puck.ch ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2008ms
rtt min/avg/max/mdev = 37.643/38.963/40.063/1.025 ms

# ping manage.mediainv.com
PING manage.mediainv.com (209.62.20.227) 56(84) bytes of data.
64 bytes from ev1s-209-62-20-227.theplanet.com (209.62.20.227): icmp_seq=1 ttl=43 time=162 ms
64 bytes from ev1s-209-62-20-227.theplanet.com (209.62.20.227): icmp_seq=2 ttl=43 time=139 ms
64 bytes from ev1s-209-62-20-227.theplanet.com (209.62.20.227): icmp_seq=3 ttl=43 time=153 ms
^C
--- manage.mediainv.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 139.206/151.776/162.182/9.514 ms

I shall check what the filtered in nmap means, but I have exactly the same output on my other server witch syncs fine.
could it be due to the version of nmap ?

Yes my /etc/services file contains the 2 lines you highlighted.

Code:

# grep 123 /etc/services 
ntp		123/tcp
ntp		123/udp				# Network Time Protocol
rmtcfg		1236/tcp			# Gracilis Packeten remote config server

I have tried to sync (with no more sucess) while iptables was "deactivated" (all policies flushed and default to accept.)
and even if I wait for any amount of time, it remains so.

Code:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.          10 l   50   64  377    0.000    0.000   0.001
 plesk2.datacent .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-frankf .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 meg.magnet.ie   .INIT.          16 u    - 1024    0    0.000    0.000   0.000