On Sunday 06 November 2005 15:49, Patrick Shanahan wrote:

* Bjørge Solli [11-06-05 09:11]:

...

I'm trying to get my Suse 9.3 to correct my time with the yast ntp-client.

I want the daemon to run in the background, and be started at bootup, so I choose the (I have it in norwegian, so this is my translation) "Start ntpd automaticly at boot time"

I try to use my universitys NTP-server rasmus.uib.no

When I press "test" now I get an error saying something like "server not available or does not answer correctly".

Only one instance of ntpd/xntpd run at one time. If you want to test sites, you must stop ntpd, ie: 'rcxntpd stop', then restart it when you have finished your test, ie: 'rcxntpd start'.

note: you must start/stop rcxntpd as root.

Then why is my clock wrong? It seems to be on speed... (too fast). It doesn't help if I use your command or /etc/init.d/xntpd stop, in yast I still get the same error:-( This is done as root: pia:/etc # /etc/init.d/xntpd restart Shutting down network time protocol daemon (NTPD) done Try to get initial date and time via NTP from rasmus.uib.no failed Starting network time protocol daemon (NTPD) done pia:/etc # cat ntp.conf ################################################################################ ## /etc/ntp.conf ## ## Sample NTP configuration file. ## See package 'xntp-doc' for documentation, Mini-HOWTO and FAQ. ## Copyright (c) 1998 S.u.S.E. GmbH Fuerth, Germany. ## ## Author: Michael Andres, ## ################################################################################ ## ## Radio and modem clocks by convention have addresses in the ## form 127.127.t.u, where t is the clock type and u is a unit ## number in the range 0-3. ## ## Most of these clocks require support in the form of a ## serial port or special bus peripheral. The particular ## device is normally specified by adding a soft link ## /dev/device-u to the particular hardware device involved, ## where u correspond to the unit number above. ## ## Generic DCF77 clock on serial port (Conrad DCF77) ## Address: 127.127.8.u ## Serial Port: /dev/refclock-u ## ## (create soft link /dev/refclock-0 to the particular ttyS?) ## # server 127.127.8.0 mode 5 prefer ## ## Undisciplined Local Clock. This is a fake driver intended for backup ## and when no outside source of synchronized time is available. ## server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized ## ## Outside source of synchronized time ## ## server xx.xx.xx.xx # IP address of server ## ## Miscellaneous stuff ## driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file server a.ntp.alphazed.net server clock.netcetera.dk server tick.keso.fi # logconfig =syncstatus + sysevents # logconfig =all # statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable # # Authentication stuff # # keys /etc/ntp.keys # path for keys file # trustedkey 1 2 3 4 5 6 14 15 # define trusted keys # requestkey 15 # key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables pia:/etc # -- Bjørge Solli

On Sunday 06 November 2005 19:24, Per Jessen wrote:

This works fine from here:

# ntpdate rasmus.uib.no 6 Nov 19:23:06 ntpdate[9185]: step time server 129.177.13.13 offset -266.355246 sec

Do your network have access to rasmus.uib.no? That is, can you ping it?

********* pia:~ # /etc/init.d/xntpd stop Shutting down network time protocol daemon (NTPD) done pia:~ # ps aux | grep ntp root 7851 0.0 0.0 1740 572 pts/7 S+ 19:41 0:00 grep ntp pia:~ # ntpdate tick.keso.fi 6 Nov 19:41:15 ntpdate[7856]: no server suitable for synchronization found pia:~ # ntpdate rasmus.uib.no 6 Nov 19:41:25 ntpdate[7860]: no server suitable for synchronization found pia:~ # ping rasmus.uib.no PING rasmus.uib.no (129.177.13.13) 56(84) bytes of data. 64 bytes from rasmus.uib.no (129.177.13.13): icmp_seq=1 ttl=244 time=259 ms 64 bytes from rasmus.uib.no (129.177.13.13): icmp_seq=2 ttl=244 time=271 ms 64 bytes from rasmus.uib.no (129.177.13.13): icmp_seq=3 ttl=244 time=248 ms 64 bytes from rasmus.uib.no (129.177.13.13): icmp_seq=4 ttl=244 time=254 ms 64 bytes from rasmus.uib.no (129.177.13.13): icmp_seq=5 ttl=244 time=315 ms --- rasmus.uib.no ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 248.081/269.808/315.151/23.987 ms pia:~ # /etc/init.d/xntpd start Try to get initial date and time via NTP from rasmus.uib.no failed Starting network time protocol daemon (NTPD) done pia:~ # ntpdate rasmus.uib.no 6 Nov 19:42:11 ntpdate[7890]: the NTP socket is in use, exiting ******** This is why I think something is really really wrong on my PC. -- Bjørge Solli

On Sunday 06 November 2005 19:52, Patrick Shanahan wrote:

* Bjørge Solli [11-06-05 13:42]:

...

Starting network time protocol daemon (NTPD) done pia:~ # ntpdate rasmus.uib.no 6 Nov 19:42:11 ntpdate[7890]: the NTP socket is in use, exiting

There *is* something wrong. You may not have two instances of ntp active at the same time. "the NTP socket is in use".

you _must_ stop ntpd before trying the ntpdate command.

If you only read the whole transcript of my commands you would have known that is exactly what I did. I just started it afterwards to show that if it runs ntpdate returns a different error..

there are several reasons why the date is not set my xntpd, one being that the date is toooo far out of of sync or it took tooo long for the initalizing.

STOP any instance of ntp, then check that none is running: ps aux|grep ntpd

run as root: ntpdate no.pool.ntp.org rasmus.uib.no no.pool.ntp.org

But since you insist, I do this again: pia:~ # /etc/init.d/xntpd stop Shutting down network time protocol daemon (NTPD) done pia:~ # ps aux|grep ntpd root 10328 0.0 0.0 1740 572 pts/7 S+ 21:32 0:00 grep ntpd pia:~ # ntpdate no.pool.ntp.org rasmus.uib.no no.pool.ntp.org 6 Nov 21:32:17 ntpdate[10332]: no server suitable for synchronization found I also manually sat the time right(+-1min) according to http://www.worldtimeserver.com/current_time_in_NO.aspx

THEN restart xntpd

pia:~ # /etc/init.d/xntpd restart Shutting down network time protocol daemon (NTPD) done Try to get initial date and time via NTP from rasmus.uib.no failed Starting network time protocol daemon (NTPD) done -- Bjørge Solli

On Sunday 06 November 2005 22:34, Patrick Shanahan wrote:

* Bjørge Solli [11-06-05 15:37]:

...

But since you insist, I do this again:

pia:~ # /etc/init.d/xntpd stop Shutting down network time protocol daemon (NTPD) done pia:~ # ps aux|grep ntpd root 10328 0.0 0.0 1740 572 pts/7 S+ 21:32 0:00 grep ntpd pia:~ # ntpdate no.pool.ntp.org rasmus.uib.no no.pool.ntp.org 6 Nov 21:32:17 ntpdate[10332]: no server suitable for synchronization found

I also manually sat the time right(+-1min) according to http://www.worldtimeserver.com/current_time_in_NO.aspx

pia:~ # /etc/init.d/xntpd restart Shutting down network time protocol daemon (NTPD) done Try to get initial date and time via NTP from rasmus.uib.no failed Starting network time protocol daemon (NTPD) done

then Carlos may be correct.

Do: grep FW_SERVICES_EXT_UDP /etc/sysconfig/SuSEfirewall2 grep ntp /etc/sysconfig/SuSEfirewall2

and report

As I answered Carlos I don't have my FW up: pia:~ # SuSEfirewall2 status SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. SuSEfirewall2: SuSEfirewall2 not active To ensure you: pia:~ # iptables -vL Chain INPUT (policy ACCEPT 89M packets, 75G bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 80M packets, 18G bytes) pkts bytes target prot opt in out source destination But as reqested: pia:~ # grep FW_SERVICES_EXT_UDP /etc/sysconfig/SuSEfirewall2 FW_SERVICES_EXT_UDP="" # see comments for FW_SERVICES_EXT_UDP # see comments for FW_SERVICES_EXT_UDP # FW_SERVICES_EXT_UDP="isakmp" pia:~ # grep ntp /etc/sysconfig/SuSEfirewall2 pia:~ # I *am* behind NAT if that matters. -- Bjørge Solli

On Monday 07 November 2005 00:01, Ulf Rasch wrote:

Can you try to sniff the comunication. (tcpdump / ethereal) That way it may be possible to see if the request is actually made.

Sure can try, but have to have a good read on the man-pages first... Too late today, will do it tomorrow. Thanks for all the help so far. -- Bjørge Solli

On 11/07/2005 04:24 AM, Bjørge Solli wrote:

<snip>

...

...

I *am* behind NAT if that matters.

Can you try to sniff the comunication. (tcpdump / ethereal) That way it may be possible to see if the request is actually made.

pia:~ # tcpdump|grep rasmus tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:23:06.863883 IP pia.ntp > rasmus.uib.no.ntp: NTPv4 client, strat 0, poll 4, prec -6

(more of the same) Your NTP packets are getting out, but no replies are coming in. I have not checked this server in the list of public access servers maintained at ntp.isc.org, but it would appear from posts by others there should be no problem just connecting to them. If you installed the xntp-doc package, there is an FAQ in /usr/share/doc/packages/xntp-doc/NTP-FAQ, specifically for this problem the file NTP-s-trouble.htm -- but for the benefit of anyone who did not install that package, your problem is usually associated with a firewall or packet filter that is not open for UDP on the ntp port. It is important to note that by default, the ntp protocol uses UDP port 123 for both source and destination ports. Wherever your NAT is happening (your internet provider perhaps?), probably they are blocking inbound traffic on privileged ports (those below 1024). Try ntpdate with the -u option to force it to select an unprivileged port as the source (you could use the -d "debug" option instead, to see more information on exactly what is happening). If that works, then my suspicion is likely correct. The downside of this is that the ntpd daemon does not seem to have the same option -- unless I missed something somewhere in the documentation, it always uses port 123 for both source and destination. If your internet provider has closed UDP port 123 for inbound traffic, you could always send them an email asking them to open it. Even if you wanted to operate ntpd in server mode, it isn't going to generate as much traffic as a web or ftp server, so I do not think such a request is unreasonable. It is even possible they did not even think to open any privileged UDP ports -- the ntp documentation even suggests this is a common failing of network administrators. If you cannot get the port opened by whoever closed it, then you still have a couple of options available: 1) there is a very good alternative to xntp, called "chrony", that I used under SuSE 6.3 and 7.2. It now works with more recent kernels (it didn't work with kernel 2.4 when I upgraded to SuSE 9.0, which is why I stopped using it), see http://chrony.sunsite.dk for details. It has separate server and client programs, but does not support any hardware reference clocks (such as a radio receiver clock or GPS receiver). So unless you have a GPS receiver connected to your system, you can try chrony (but then you don't need an external NTP server anyway :) ). In client mode, you can set the source port to something other than 123 as a config file option. Chrony uses what seems to be a very good linear regression routine to determine the current system clock corrections, which is why I like it. 2) set up ntpdate to run as a cron task in the root crontab, with the -u option of course. Once an hour should keep your clock reasonably accurate, unless your computer runs extremely fast or slow (an error of 100 parts per million equals a clock error of 0.36 seconds per hour). If so, the uncorrected system clock frequency can be calculated manually, and set at boot time (for example, using ntptime, also part of the xntp package), or you can simply run the cron task more frequently.

Bjørge Solli wrote:

NAT is the reason. When I opened port 123 in the NAT it works:-) In Norway most ISPs provide each ADSL-sub with a ADSL-router with NAT (not the normal ADSL-modem). A good thing[TM], except in this situation.

I would say it's a little unusual that you have to explicitly allow for outbound NAT'ing of certain ports and traffic. Inbound (DNAT'ing) I can understand, but outbound is a little strange to me. My Zyxel router used to do NAT'ing for me, and only on inbound did I need to set up ports and such. /Per Jessen, Zürich

Bjørge Solli wrote:

The Netopia router has NAT *and* a filter.

So does the Zyxel box - it's just fully open on outbound by default. Anyway, glad you got it to work. /Per Jessen, Zürich

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2005-11-06 at 13:52 -0500, Patrick Shanahan wrote:

STOP any instance of ntp, then check that none is running: ps aux|grep ntpd

run as root: ntpdate no.pool.ntp.org rasmus.uib.no no.pool.ntp.org

THEN restart xntpd

Also, the start script "/usr/sbin/rcxntpd" calls ntpdate prior to starting the xntpd daemon. Ie, it first sets the clock in one shot, then starts the daemon to keep the clock in sync. But the OP tried the correct sequence and failed: pia:~ # /etc/init.d/xntpd stop Shutting down network time protocol daemon (NTPD) done pia:~ # ps aux | grep ntp root 7851 0.0 0.0 1740 572 pts/7 S+ 19:41 0:00 grep ntp pia:~ # ntpdate tick.keso.fi 6 Nov 19:41:15 ntpdate[7856]: no server suitable for synchronization found So I think this is symptomatic of firewall problem. I had that problem. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDbmsYtTMYHG2NR9URAj/rAJ92ZUdxRHu/TtEfcNLUAV5ebMo5YgCfefxm nB98hBdfPYgvg2MOgOoZZZg= =/c5c -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2005-11-06 at 18:14 -0500, Bruce Marshall wrote:

In the /etc/ntp.conf file you displayed earlier, I find *no* reference to rasmus.uib.no so I suspect your ntp is using some other file as a conf file.

That could be the start of your problems.

No, he is issuing the command "ntpdate rasmus.uib.no" manually. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDbrqBtTMYHG2NR9URAvEAAJ4lKbf/4WY7rOgcdoQFYTZDqqfvVwCfQQ+N lJCSpIyjRjI7EmZZsHE01Kg= =/8z4 -----END PGP SIGNATURE-----

Bjørge Solli wrote:

No, he has a point. When I start it with init.d I still get rasmus.uib.no even though I have changed it in the config. But that doesn't explain why 'ntpdate rasmus.uib.no' fails, or does it?

No, it doesn't. When ntpd is not running, you should be able to do an "ntpdate <server>" and have the clock set. For whatever reason you can't get through to the time-servers you've mentioned. I'm guessing it goes for all time-servers - do you see the same prblem for e.g. metasweb01.admin.ch or ntp.ien.it ? /Per Jessen, Zürich

Bjørge Solli wrote:

On Monday 07 November 2005 11:48, Per Jessen wrote:

...

I'm guessing it goes for all time-servers - do you see the same prblem for e.g. metasweb01.admin.ch or ntp.ien.it ?

Yes. See my other reply on errors from other machine and other OS.

Then I think what Dave Howorth wrote is probably right:

Does your ISP make an NTP server available? Perhaps they do that and block access to other time servers to reduce load on them.

I don't know if kvarteret.no is your provider, but the address 'ntp.kvarteret.no' does exist. When I tried it: ntpdate ntp.kvarteret.no 7 Nov 13:03:51 ntpdate[11730]: no server suitable for synchronization found Maybe it works for you. /Per Jessen, Zürich

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-11-07 at 10:51 +0100, Bjørge Solli wrote:

...

No, he is issuing the command "ntpdate rasmus.uib.no" manually.

No, he has a point. When I start it with init.d I still get rasmus.uib.no even though I have changed it in the config. But that doesn't explain why 'ntpdate rasmus.uib.no' fails, or does it?

Do you have xntpd in a chroot? Check file "/etc/sysconfig/xntp": ## Type: yesno ## Default: yes ## ServiceRestart: xntpd # # Shall the time server ntpd run in the chroot jail /var/lib/ntp? # # Each time you start ntpd with the init script, /etc/ntp.conf will be # copied to /var/lib/ntp/etc/. # # The pid file will be in /var/lib/ntp/var/run/ntpd.pid. # XNTPD_RUN_CHROOTED="yes" Try to set it to no. However, it shouldn't affect ntpdate I'd have a go with "ethereal". - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDb1RrtTMYHG2NR9URApn2AKCX7SLyH7A1tZ9cG15fm74NxyVHSACfTpMN 0BEOgbwx0AW7K+VW9bo8erQ= =++1b -----END PGP SIGNATURE-----

* Joachim Schrod [11-07-05 11:30]:

ntpq -c pe

It tells you about all time sources, which one is used currently, and if you're synchronized.

Of this display, what indicates you are synchronized? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

* Joachim Schrod [11-07-05 13:21]:

This means I'm synchronized to PTB, and if that connection gets lost, rustime01 and hora could take over. (All three servers are stratum 1 servers and give definitive times. PTB is the reference time source for Germany.)

Thankyou, your posts have been very informative. Wading thru the ntp documentation is much worse that trying to understand some of the man pages that I preach so much about. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

Dave Howorth wrote:

On Mon, 2005-11-07 at 19:21 +0100, Joachim Schrod wrote:

...

E.g., my internal time server has the output

remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) LOCAL(0) 10 l - 64 377 0.000 0.000 0.008 *ntp2.ptb.de .PTB. 1 u 887 1024 377 44.424 0.697 0.826 +rustime01.rus.u .DCFp. 1 u 968 1024 377 38.228 -2.858 0.927 +hora.cs.tu-berl .PPS. 1 u 3 1024 377 48.561 -3.353 1.365

This means I'm synchronized to PTB, and if that connection gets lost, rustime01 and hora could take over. (All three servers are stratum 1 servers and give definitive times. PTB is the reference time source for Germany.)

I don't know your situation, but many readers of this list are individuals rather than network administrators, so perhaps it's worth pointing out for those who don't know that individuals should generally not use stratum 1 servers.

Well, I serve my internal network with some 50 machines on it. I.e., I don't exactly follow the rules you cited. ;-) But it should be noted that there are almost no stratum 2 ntp servers for Germany. (If I wouldn't pay my Internet connection by traffic, I would make one available.) Thus one either has to use the NTP Pool (you'll know it probably, but other readers may want to refer to http://ntp.isc.org/bin/view/Servers/NTPPoolServers), or to stratum 1 servers. Of course, when using an upstream ntp server, a notification message to that server's admin is always in order, even if they didn't ask for it. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany

On Sunday 06 November 2005 09:22 pm, Carlos E. R. wrote:

The Sunday 2005-11-06 at 18:14 -0500, Bruce Marshall wrote:

...

In the /etc/ntp.conf file you displayed earlier, I find *no* reference to rasmus.uib.no so I suspect your ntp is using some other file as a conf file.

That could be the start of your problems.

No, he is issuing the command "ntpdate rasmus.uib.no" manually.

-- Cheers, Carlos Robinson

Didn't look like that to me. In he showed he was doing an rcxntpd restart and in the middle of all that it had the rasmus failure. But whatever....

On Monday 07 November 2005 02:38 pm, Carlos E. R. wrote:

The Monday 2005-11-07 at 12:12 -0500, Bruce Marshall wrote:

...

...

No, he is issuing the command "ntpdate rasmus.uib.no" manually.

Didn't look like that to me. In he showed he was doing an rcxntpd restart and in the middle of all that it had the rasmus failure. But whatever....

Fourth command: |> pia:~ # /etc/init.d/xntpd stop |> Shutting down network time protocol daemon (NTPD) |> done pia:~ # ps aux | grep ntp |> root 7851 0.0 0.0 1740 572 pts/7 S+ 19:41 0:00 grep |> ntp pia:~ # ntpdate tick.keso.fi |> 6 Nov 19:41:15 ntpdate[7856]: no server suitable for synchronization |> found pia:~ # ntpdate rasmus.uib.no

Here's what I was looking at: (Sunday) It doesn't help if I use your command or /etc/init.d/xntpd stop, in yast I still get the same error:-( This is done as root: pia:/etc # /etc/init.d/xntpd restart Shutting down network time protocol daemon (NTPD)                    done Try to get initial date and time via NTP from rasmus.uib.no          failed Starting network time protocol daemon (NTPD)                         done pia:/etc # cat ntp.conf ################################################################################ ## /etc/ntp.conf ## ## Sample NTP configuration file. ## See package 'xntp-doc' for documentation, Mini-HOWTO and FAQ. ## Copyright (c) 1998 S.u.S.E. GmbH Fuerth, Germany. ## ## Author: Michael Andres,   ## ################################################################################ ## ## Radio and modem clocks by convention have addresses in the ## form 127.127.t.u, where t is the clock type and u is a unit ## number in the range 0-3. <snip> No extra commands that I see..

-- Cheers, Carlos Robinson

On Mon, 2005-11-07 at 17:06 -0500, Jerry Feldman wrote:

On Monday 07 November 2005 4:34 pm, Bruce Marshall wrote:

...

It doesn't help if I use your command or /etc/init.d/xntpd stop, in yast I still get the same error:-(

This is done as root:

pia:/etc # /etc/init.d/xntpd restart Shutting down network time protocol daemon (NTPD) done Try to get initial date and time via NTP from rasmus.uib.no failed Starting network time protocol daemon (NTPD) This indicates to me one of a couple of things: First, rasmus.uib.no is not responding to time (ntp or ntpdate) inquiries, but I think that has been resolved.

Second, You do not have port 123 opened eitehr in your firewall or router. This is a UDP query, and therefore, you need to allow incoming traffic on UDP port 123.

Hmmm. I use a Linksys WRT54G router/firewall and have no such problem. All outside access blocked except for what I allow and port 123 is not one of them. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-11-07 at 16:34 -0500, Bruce Marshall wrote:

Here's what I was looking at: (Sunday)

Perhaps at the wrong one. I think you were looking at: Date: Sun, 06 Nov 2005 18:35:39 +0100 From: Bjørge Solli instead of: Date: Sun, 06 Nov 2005 19:43:15 +0100 From: Bjørge Solli Perhaps you don't have threaded sort activated and you didn't notice the order. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDcAAJtTMYHG2NR9URAo9/AJ95z/eF4kDIPaEqPp5t763O2h0phgCfWXML s03VAEjI9ieHwTO2U077yps= =FGla -----END PGP SIGNATURE-----

On Sunday 06 November 2005 20:25, Carlos E. R. wrote:

The Sunday 2005-11-06 at 18:35 +0100, Bjørge Solli wrote:

...

It doesn't help if I use your command or /etc/init.d/xntpd stop, in yast I still get the same error:-(

This is done as root:

pia:/etc # /etc/init.d/xntpd restart Shutting down network time protocol daemon (NTPD) done Try to get initial date and time via NTP from rasmus.uib.no failed Starting network time protocol daemon (NTPD) done

There will be more info in your log:

...

...

logfile /var/log/ntp # alternate log file

6 Nov 15:17:23 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:18:26 ntpd[1013]: kernel time sync enabled 0001 6 Nov 15:18:26 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:19:31 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:20:35 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:21:38 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:22:44 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:23:48 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:24:52 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:25:57 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:27:02 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:29:12 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:33:29 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:42:03 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:59:10 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 16:16:17 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 16:33:21 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 16:50:26 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 17:07:31 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 17:24:37 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 17:41:42 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 17:58:46 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 18:15:50 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 18:23:54 ntpd[953]: ntpd exiting on signal 15 6 Nov 18:24:17 ntpd[1013]: ntpd exiting on signal 15 6 Nov 18:24:31 ntpd[4882]: ntpd exiting on signal 15 6 Nov 18:27:26 ntpd[5015]: ntpd exiting on signal 15 6 Nov 18:28:31 ntpd[5087]: ntpd exiting on signal 15 6 Nov 18:28:46 ntpd[5156]: ntpd exiting on signal 15 6 Nov 18:29:00 ntpd[5196]: ntpd exiting on signal 15 6 Nov 18:29:29 ntpd[5226]: ntpd exiting on signal 15 6 Nov 18:30:38 ntpd[5287]: ntpd exiting on signal 15 6 Nov 18:31:08 ntpd[5451]: ntpd exiting on signal 15 6 Nov 18:32:13 ntpd[5493]: ntpd exiting on signal 15 6 Nov 18:35:33 ntpd[5553]: synchronized to LOCAL(0), stratum 10 6 Nov 18:35:33 ntpd[5553]: kernel time sync disabled 0041 6 Nov 18:36:36 ntpd[5553]: kernel time sync enabled 0001 6 Nov 18:43:03 ntpd[5553]: ntpd exiting on signal 15 6 Nov 18:43:31 ntpd[5872]: ntpd exiting on signal 15 6 Nov 19:45:24 ntpd[7886]: synchronized to LOCAL(0), stratum 10 6 Nov 19:45:24 ntpd[7886]: kernel time sync disabled 0041 6 Nov 19:46:27 ntpd[7886]: kernel time sync enabled 0001 6 Nov 21:28:01 ntpd[7886]: ntpd exiting on signal 15 6 Nov 21:36:47 ntpd[10390]: synchronized to LOCAL(0), stratum 10 6 Nov 21:36:47 ntpd[10390]: kernel time sync disabled 0041 6 Nov 21:37:50 ntpd[10390]: kernel time sync enabled 0001 I don't understand it.

and '/var/log/messages'. But I'd guess you have the service closed in the firewall; open it:

FW_SERVICES_EXT_UDP="ntp"

I have turned off my FW, but I am behind NAT (ADSL Router with NAT). I ran a tail -f /var/log/messages and ran the following in a diffent window: pia:~ # /etc/init.d/xntpd stop Shutting down network time protocol daemon (NTPD) done pia:~ # ntpdate no.pool.ntp.org rasmus.uib.no no.pool.ntp.org 6 Nov 22:07:50 ntpdate[11305]: no server suitable for synchronization found Nothing was added to /var/log/messages -- Bjørge Solli

* Carlos E. R. [11-06-05 20:34]:

Wild shot: get a copy of the configuration file from the rpm, and redo yours from scratch.

...

I don't understand it.

Me neither.

My logs show that I started getting the "Bad file descriptor" error: 29 Oct 10:01:51 ntpd[31709]: time reset +0.294794 s 29 Oct 10:05:06 ntpd[31709]: synchronized to 69.17.57.162, stratum 3 29 Oct 10:07:12 ntpd[31709]: synchronized to 66.187.233.4, stratum 1 29 Oct 10:39:07 xntpd[698]: sendto(216.27.160.99): Bad file descriptor 29 Oct 10:39:08 xntpd[698]: sendto(69.248.14.194): Bad file descriptor 29 Oct 10:39:09 xntpd[698]: sendto(24.220.160.49): Bad file descriptor I also notice that the log indicates it went from ntpd to xntpd ??? I stopped xntpd (rcxntpd stop), ran ntpdate, then restarted xntpd: 5 Nov 08:50:10 ntpd[14470]: synchronized to 209.204.159.18, stratum 2 5 Nov 08:56:42 ntpd[14470]: synchronized to 64.142.103.194, stratum 1 and the error was gone. note: returned from xntpd to ntpd My ntp.conf has only five instances of 'us.pool.ntp.org' and the 'driftfile' and 'logfile' entries. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-11-07 at 12:59 +1100, scsijon wrote:

...

...

6 Nov 15:19:31 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor

Weird! I did not expect that. I had a look at the source code, but I get no clue what it can _really_ mean. And the documentations does not mention that error, I grepped for it. /cut

If it was windows i'd say it was trying to send a filename of a length not acceptable to send (too long). Alternately are you trying to send a filename with an unacceptable character in the name (there are a few such as the Null)? Many firewalls and ISP's won't pass these as they allow filehiding.

We are talking of the ntpd clock update protocol and daemon. The OP is not sending any file at all, and we have no idea what file the log is referring to. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDbsOztTMYHG2NR9URAs36AJ0U1fVNGjYy7Ot7XL2w3wQiRE/6MQCeIQoA H/QlW6H/tMgFemw4u9vhco0= =u227 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-11-07 at 00:04 -0500, Synthetic Cartoonz wrote:

...

We are talking of the ntpd clock update protocol and daemon. The OP is not sending any file at all, and we have no idea what file the log is referring to.

It's not sending a file per se. It's sending (writing) and receiving (reading) a stream of bytes in the protocol for ntp. If the code snippet posted earlier is the correct place the "Bad file descriptor" message is being generated,

I got it from the second dvd (suse 9.3), grepping for that error message (using mc instead of installing the rpm): it was the only place where I found it, in file "ntp_io.c". I can't follow the coding there, too complex / few comments / docs.

I don't have the code for ntp handy.

I could email that file to you, but not more: I don't have much bandwidth. Or you can get it by ftp from most mirrors. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDb1XBtTMYHG2NR9URAoSYAJ4owyn2gy/JA6Aj0SxQae7wSp8B+QCeKKEP Z/di1wxxsnEcl/caVBP6Sns= =4asA -----END PGP SIGNATURE-----

On Monday 07 November 2005 01:31, Carlos E. R. wrote:

The Sunday 2005-11-06 at 22:09 +0100, Bjørge Solli wrote:

...

...

...

logfile /var/log/ntp # alternate log file

6 Nov 15:17:23 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:18:26 ntpd[1013]: kernel time sync enabled 0001 6 Nov 15:18:26 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor 6 Nov 15:19:31 ntpd[1013]: sendto(129.177.13.13): Bad file descriptor

Weird! I did not expect that. I had a look at the source code, but I get no clue what it can _really_ mean. And the documentations does not mention that error, I grepped for it.

if (err == EBADF) { int j, b;

fds = activefds; for (j = 0; j <= maxactivefd; j++) if ( (FD_ISSET(j, &fds) && (read(j, &b, 0) == -1)) ) netsyslog(LOG_ERR, "Bad file descriptor %d", j); }

and "j" is missing from your log output.

So is "sendto", which is a clue that you're looking at the wrong section of code. The correct section prints the error message at line 1537 of ntpd/ntp_io.c The file descriptor that is bad is the connection to the remote time server. Why it's bad is another question. The code in question doesn't seem to be checking many return values, so the fd could be bad in a number of places, including, as far as I can see, not being opened in the first place (too many open files, perhaps?!) There are also too many #if sections to wade through to be able to follow the code easily, but since it's a transient error, my guess would be something like too many open files or something similar

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-11-07 at 06:32 +0100, Anders Johansson wrote:

On Monday 07 November 2005 06:27, Anders Johansson wrote:

...

The file descriptor that is bad is the connection to the remote time server.

Poor choice of words. It is the local socket in the connection to the remote time server. IOW something that normally never should fail

What is poor is the choice of error messages given to the user by the original programmer; without being skilled programmers we can not guess what is wrong. And I grepped for that error message in the extensive included documentation, and didn't find it. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDb1crtTMYHG2NR9URAi92AJ40tfiDM+sPYXjLUT71rCvgheKUXwCbB6jD q+xFg27jQC69v0PVNGjugYE= =6PDj -----END PGP SIGNATURE-----

On Mon, 2005-11-07 at 11:18 +0100, Bjørge Solli wrote:

On Monday 07 November 2005 06:27, Anders Johansson wrote:

...

The file descriptor that is bad is the connection to the remote time server. Why it's bad is another question. The code in question doesn't seem to be checking many return values, so the fd could be bad in a number of places, including, as far as I can see, not being opened in the first place (too many open files, perhaps?!)

There are also too many #if sections to wade through to be able to follow the code easily, but since it's a transient error, my guess would be something like too many open files or something similar

OK. This new scenario in mind I tested a bit:

Test on laptop (other machine) running suse 9.3: same error! Test on laptop running Knoppix 3.3: same error!

Ok, should seem to me that my ISP[1]/router[2] does something nasty. If no other suggestions come here I will try asking the ISP and other ppl in my local LUG with the same connection.

Does your ISP make an NTP server available? Perhaps they do that and block access to other time servers to reduce load on them. Cheers, Dave