https://bugzilla.novell.com/show_bug.cgi?id=337075 Mark Gordon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtgordon@novell.com AssignedTo|bnc-team-screening@forge.provo.novell.com |mskibbe@novell.com Severity|Normal |Major -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075#c2 Michael Skibbe changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |martin.burnicki@meinberg.de --- Comment #2 from Michael Skibbe 2007-11-05 02:29:54 MST --- i'm not really understanding - xntp is starting to early because the init script checks if network is up. networkmanager tell this when he is started but not then the interfaces are up - this annoying! but after each interface up/down xntp is restartet so it stops and start like before only with network interface up. but btw are you really using networkmanager? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075#c4 --- Comment #4 from Michael Skibbe 2007-11-06 02:21:48 MST --- 1) (yes, i'm native german) the person in the thread you pointed above used networkmanager so the bug finding is simple :-D 2) comment #1 reffers partly on the nm-ntp problem but the initial problem is the same as here. 3) i'm not sure which kind of network managment tool is used as standard (nm or ifup/ifdown) 4) if you type in rcntp restart the init script will stop and start the service. the stop contains in line #211 a killproc. the "old" ntp should not listen on the device/port. 5) ntp will be restarted _only_ with networkmanager enabled. please check this with # grep NETWORKMANAGER /etc/sysconfig/network/config 6) i take a look on the "-g" option but i'm working on a other solution to fix the nm-ntp problem. this bugfix should fix your problem (if you are not using nm), too. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075#c6 --- Comment #6 from Martin Burnicki 2007-11-06 07:07:11 MST --- (In reply to comment #4 from Michael Skibbe)

1) (yes, i'm native german) the person in the thread you pointed above used networkmanager so the bug finding is simple :-D

2) comment #1 reffers partly on the nm-ntp problem but the initial problem is the same as here.

3) i'm not sure which kind of network managment tool is used as standard (nm or ifup/ifdown)

From my observations nm is used as default on laptops whereas ifup/ifdown is preferred on workstations/servers. This makes sense, IMHO.

4) if you type in rcntp restart the init script will stop and start the service. the stop contains in line #211 a killproc. the "old" ntp should not listen on the device/port.

Yes, I know. If I type "rcntp restart" after the final runlevel has been reached then ntpd starts up and works fine, even if it ntpd has not been running before.

5) ntp will be restarted _only_ with networkmanager enabled. please check this with # grep NETWORKMANAGER /etc/sysconfig/network/config

pc-martin5:~ # grep NETWORKMANAGER /etc/sysconfig/network/config NETWORKMANAGER=no # This variable has no effect if NETWORKMANAGER=no # This variable has no effect if NETWORKMANAGER=no The output above is from the same systen as the messages in my initial report, so this clearly indicates that it is started twice even though networkmanager is _not_ used.

6) i take a look on the "-g" option but i'm working on a other solution to fix the nm-ntp problem. this bugfix should fix your problem (if you are not using nm), too.

I'm involved in the development of the NTP package (search for "burnicki" in NTP's bugzilla), though I'm mainly testing and trying to find/fix bugs. So if you let me know some details I can give you some hints or comments from NTP's point of view ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075#c8 Michael Skibbe changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |martin.burnicki@meinberg.de --- Comment #8 from Michael Skibbe 2007-11-14 01:00:33 MST --- please provide boot log, /var/log/messages and /var/log/ntp -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075#c10 Michael Skibbe changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |martin.burnicki@meinberg.de --- Comment #10 from Michael Skibbe 2007-11-22 03:11:44 MST --- i worked on a solution to get the timing fine. can you please test these packages? http://download.opensuse.org/repositories/home:/mskibbe/openSUSE_10.3/x86_64... http://download.opensuse.org/repositories/home:/mskibbe/openSUSE_10.3/x86_64... or http://download.opensuse.org/repositories/home:/mskibbe/openSUSE_10.3/i586/n... http://download.opensuse.org/repositories/home:/mskibbe/openSUSE_10.3/i586/n... but please remind - these are only testing packages without warranty. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075#c12 Michael Skibbe changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |martin.burnicki@meinberg.de --- Comment #12 from Michael Skibbe 2007-11-28 04:10:58 MST --- sorry for the long delay. i fixed the "bugs" you told me but the apparmor profiles aren't in the ntp package. if you want you can test fixed packages: http://download.opensuse.org/repositories/home:/mskibbe/openSUSE_10.3/i586/n... http://download.opensuse.org/repositories/home:/mskibbe/openSUSE_10.3/i586/n... http://download.opensuse.org/repositories/home:/mskibbe/openSUSE_10.3/x86_64... http://download.opensuse.org/repositories/home:/mskibbe/openSUSE_10.3/x86_64... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075#c14 --- Comment #14 from Martin Burnicki 2007-11-30 01:51:09 MST --- Michael, I'm currently running some more tests. Maybe some of the behaviour I described in my previous comment is due to my network setup. Please wait until I have found out more details before you continue to work on this. Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075 User martin.burnicki@meinberg.de added comment https://bugzilla.novell.com/show_bug.cgi?id=337075#c16 Martin Burnicki changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|martin.burnicki@meinberg.de | --- Comment #16 from Martin Burnicki 2007-12-14 06:10:11 MST --- Michael, sorry for the delay. I didn't get to this time consuming tests earlier. The special network setup I mentioned in my previous comment was related to some tests with an additional USB network interface. When this interface had been configured with yast then the bootscripts waited for that "mandatory interface", and if that USB device was not plugged in at startup the scripts returned an error. I was in doubt whether this would affect ntpd startup, or not. I've now tested with a fresh 10.3 installation once more. Here's an updated summary of the tests on 2 machines: 1.) a standard AMD64/x86_64 machine with a PCI network card, using ifup method 2.) a i386 laptop using network manager First removed ntp RPMs which have been shipped witht he distribution, and removed all ntp files below /etc. Then installed new RPMs (ntp-4.2.4p4-34.1.*) from your download page, which are newer than the version I had tested for my previous comment. Looks like the RPMs now install a file /etc/ntp.servers to avoid the error messages I mentioned earlier. However, the rcntp script still uses a file /etc/ntp.server (without 's'), so the /etc/ntp.servers file is simply ignored and the error messages persist: # rcntp start Starting network time protocol daemon (NTPD)cp: cannot stat `/etc/ntp.server': No such file or directory grep: /etc/ntp.server: No such file or directory done Then tried: # rcntp addserver 0.pool.ntp.org mv: cannot stat `/etc/ntp.server': No such file or directory /usr/sbin/rcntp: line 205: /etc/ntp.server~: No such file or directory Anyway, after the command "addserver" command has been run the file /etc/ntp.server exists and contains the server line. The next command # rcntp addserver 1.pool.ntp.org works correctly and doesn't give an error. I'd propose to use the name /etc/ntp.servers, and thus fix the rcntp script to use this name. In order to speed up synchronization the "iburst" keyword should be used with each server. I can't imagine any case where this would not be useful. A question is whether it's wiser to let that keyword be added automatically by the "addserver" function in the rc script, or whether it should be supplied on the command line for the rc script. E.g. if I run rcntp addserver 0.pool.ntp.org iburst then the "iburst" keyword is added to the server line in /etc/ntp.server. When I restart ntpd using the rcntp script then synchronization is pretty fast. Then I've activated ntp using yast's runlevel editor since otherwise ntpd would not be started after reboot, and restarted both machines with network cables plugged in. Using the ipup method, ntpd starts fine after reboot. On the laptop, however, the ntpq -p billboard shows only an entry for the local clock, not for the configured servers. I think the problem here is that the network interface appears later, when it has been started by the network manager. The actual version of ntpd scans dynamically for network interfaces. However, this happens at an interval which is 5 minutes by default, and can be configured for as small a 60 seconds, it the parameter "-U 60" is given on ntpd's command line. You can see in the log messages when ntpd has discovered the new interface. So the "addserver" command is applied after the network interface has been initialized, but before it has been recognized by the running ntpd. As already mentioned before, I think a proper solution could be to send a signal to ntpd when a new network interface becomes available so that ntpd can discover it, and then run the addserver commands. Unfortunately ntpd does not support that kind of signalling, yet. If I run "rcntp addserver 2.pool.ntp.org iburst" after ntpd has discovered the network interface then the new server association appears in the ntpq billboard and ntpd quickly synchronizes to it (due to the "iburst" keyword). If I run "rcntp restart" on the laptop after the new network interface is up then everything works fine, too. I've also noticed that now "ntpq -p" is run for "rcntp status". That's fine. I'll keep on trying to find a better solution for the usage with network manager. Maybe for now you could handle the two cases differently: For if-up as-is, and for NM restart ntpd after the first network interface has become available. What's to be done is fix the name of the ntp.server(s) file in rcntpd, and modify apparmor according to the new needs. Also the yast module for ntp should be adapted. (see also bug #334206, https://bugzilla.novell.com/show_bug.cgi?id=334206) Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075 User martin.burnicki@meinberg.de added comment https://bugzilla.novell.com/show_bug.cgi?id=337075#c18 --- Comment #18 from Martin Burnicki 2008-01-07 08:55:48 MST --- Michael, (In reply to comment #17 from Michael Skibbe)

yast there is no need to fix the yast module because i want to drop the ntp.server(s) file(s) and only use the ntp.conf

I've seen this in the latest versions in your home repo (4.2.4p4-36.1).

i have to take a look into code / doc if there is an other way to tell ntp to listen on a new device.

In the meantime I've also made some tests on a laptop with Network Manager. Unfortunately this has not been successful: I've configured 3 pool servers plus the local clock, which is there by default. - If I run "ntpq -p" immediately after reboot then it says: "No association IDs returned". This happens regardless of whether the LAN (cable) is connected during boot, or not. This means there's not even an association for the local clock, which I find quite weird. - After I've run "rcntp restart" the "ntpq -p" billboard shows the local clock, and also the pool servers if the network is already reachable. I've also talked to Frank Kardel who is one of the core developers of NTP. He told me that he would expect the dynamic configuration to work correctly. However, the "dynamic" keyword would be required for the server associations. The "dynamic" keyword had been introduced to workaround some problems which can arise if the NTP daemon starts before the network is up. In the current development version (which will become the next release) that keyword has been obsoleted, and the behaviour introduced with "dynamic" has become the default. According to Frank, the best solution would be to use the routing socket to be able to react on network changes. However, as Frank says, the way routing sockets are implemented under Linux differs strongly from the implentation under other Unix-like systems, so "someone" would have to implement the routing socket support for Linux in ntpd. Anyway, even the "dynamic" keyword used in the stable version 4.2.4p4-63.1 does not seem to help. BTW, I've seen: # ps ax |grep ntp 4549 ? Ss 0:00 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid \ -g -u ntp -U 60 -i /var/lib/ntp -c /etc/ntp.conf~ Is it intentional that /etc/ntp.conf~ (a backup file) is used as configuration file?

thanks for your testing!

I'm happy if I can help. I'd also appreciate if NTP runs under Linux without problems. Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075 User martin.burnicki@meinberg.de added comment https://bugzilla.novell.com/show_bug.cgi?id=337075#c20 --- Comment #20 from Martin Burnicki 2008-01-07 14:55:16 MST --- (In reply to comment #18 from Martin Burnicki)

In the meantime I've also made some tests on a laptop with Network Manager.

Unfortunately this has not been successful:

I've configured 3 pool servers plus the local clock, which is there by default.

- If I run "ntpq -p" immediately after reboot then it says: "No association IDs returned". This happens regardless of whether the LAN (cable) is connected during boot, or not. This means there's not even an association for the local clock, which I find quite weird.

- After I've run "rcntp restart" the "ntpq -p" billboard shows the local clock, and also the pool servers if the network is already reachable.

Hm, my latest tests with NM were a little bit too fast. The update to the latest NTP RPM had undone my sysconfig modification "-U 60" which should let ntpd rescan the network interfaces once every 60 seconds rather than every 5 minutes or so. So I'd have had to wait longer for the interface rescan. Under certain conditions ntpd finds the configured servers after a port rescan even if it had been started before the network connection is up. So there's still hope and I'll investigate more on this. I think the final goal should be to get ntpd working correctly without having to add the servers from ntp.conf dynamically. Dynamical configuration is great, however, if the IPs of the upstream server are passed via DHCP. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075 User martin.burnicki@meinberg.de added comment https://bugzilla.novell.com/show_bug.cgi?id=337075#c22 --- Comment #22 from Martin Burnicki 2008-01-08 09:18:14 MST --- Michael, I've now done some additional tests with NM. (In reply to comment #21 from Michael Skibbe)

the ntp.conf~ was only a temporary file which is created and deleted by the init script. i renamed this file ntp.conf.tmp.

I've seen that this when I had a look at the rc script. I'd appreciate if we could it working without having to ntp.conf file and found that it basically works. Finally it's mostly a timing problem. See below.

i didn't find information about dynamic keyword, yet. but i think there is an alternative!

I'm afraid we need the "dynamic" keyword anyway in ntp.4.2.4. It is used to indicate that a peer configuration can be done later, even if currently no interface can be determined for that peer address. Look for FLAG_DYNAMIC in ntp_peer.c. Please note this has become the default behaviour in the current ntp-dev, so in the next stable release this keyword will be obsolete, but the behaviour will be same as now with "dynamic". What I've done and observed so far is: - Modified the rc script such that it doesn't touch the ntp.conf file - Run ntpd with the standard ntp.conf file and "-U 60" - Removed the /etc/sysconfig/network/*ntp script - Stopped ntpd - Set system time 2 hours past - Reboot without network connection - After reboot "local clock" is shown by "ntpq -p" - Connected network cable - New interface detected by ntpd < 60 secs later - DNS resolving of peers ~5 mins later (see below) - Associations added after DNS success - Synchronizing to pool server The ugly things are: - It takes up to 60 seconds until the interface is detected - It takes even more until DNS resolving is retried and succeeds

ntpdc allows to rescan devices with ifreload. the init script now reload the interfaces when nm told it that a device changed. this _should_ work and fix your problem from comment #20. are you able to test this?

Yes. This is a very good good idea. I hope this also speeds up the DNS lookup. This ntpdc command should be put into the /etc/sysconfig/network/*ntp file, and nothing else, if possible. And there's one more problem: If it takes some time until the network connection comes up then ntpd synchronizes to the "local clock" association before, which obviously "eats up" the "-g" parameter. This means if the initial time offset exceeds 1000 seconds then ntpd stops itself. A workaround for this should be to remove the local clock from ntp.conf. The "local clock" time source is only a fallback which shall allow ntpd to serve it's time to other clients even if no upstream server is available. More tests to come.

the -U method isn't a real solution for the problem because nm should tell the init script immediately after a interface change to load the server and i'm willing to wait 60 seconds.

Right. I'd also appreciate if the ntpdc ifreload command would make this obsolete. However, the best solution would be if ntpd could receive network routing information through the routing socket. Don't you know one of your colleagues at Novell who's familiar with the Linux routing sockets and could help to port the implementation of those sockets in ntpd to Linux? Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075 User martin.burnicki@meinberg.de added comment https://bugzilla.novell.com/show_bug.cgi?id=337075#c23 --- Comment #23 from Martin Burnicki 2008-01-09 09:41:17 MST --- I've made some more tests today and here are some additional notes: 1.) The "local clock" (127.127.1.0) should not be in the configuration file by default. If it is then ntpd selects it as system peer if no upstream servers are reachable (in ntp-dev this takes just a few seconds). Once this has happened it takes a very long time until ntpd synchronizes to the upstream servers when they become reachable. If the initial time offset then exceeds ntpd's so called sanity limit ntpd stops itself. Checking the sanity limit can be disabled by a "tinker panic 0" entry in ntp.conf, but this would not solve all problems. If the "local clock" had been selected as system peer before and the initial time offset would require the system clock to be stepped then the step happens only after the "reach" of the upstream server has increased to "77", i.e. after 6 or 7 polling cycles. Unfortunately ntpd increases the polling interval in this case quickly up to 1024, so it might take up to ~7000 seconds until the system time would initially be set correctly. This is not acceptable. So, since the "local clock" entry is not required in most cases, it should not be there by default. The "local clock" makes sense only if the machine shall also act as a NTP time server. Normally such machines have a continuous network connection, so the proplems discussed here don't apply in that case. 2.) Notifying ntpd using "ntpdc -c ifreload" whenever a new network interface has become available or unavailable works very well. However, this requires symmetric key authentication for ntpdc and should only be used as a workaround as long as ntpd does not support the routing socket under Linux. Anyway, this eliminates the delay until ntpd would detect the new interface automatically. 3.) Once the first network interface has become available the DNS service should be useable to resolve the host names of the upstream servers. Ntpd runs a resolver thread which waits until DNS is ready to resolve those names. Unfortunately the retry interval for the resolver starts at 60 seconds and increases by doubling (i.e. 120, 240, ...) every time an unsuccessful DNS lookup has been made. This is really ugly since this means the longer it takes after system boot until the network becomes available, the longer it takes _after_ the network has become available until ntpd can start querying the upstream servers. Fixing this requires a patch for ntpd which triggers a DNS retry whenever a new interface has been detected. I'm going to contact some of the NTP developers to see how this can be implemented properly. Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075 Michael Skibbe changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|351059 | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075 Andreas Schneider changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|anschneider@novell.com |varkoly@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=337075 User martin.burnicki@meinberg.de added comment https://bugzilla.novell.com/show_bug.cgi?id=337075#c27 --- Comment #27 from Martin Burnicki 2008-03-31 01:55:52 MST --- Peter, (In reply to comment #26 from Peter Varkoly)

this must be fixed by the ntp-developers

I know this issue has just recently been assigned to you. However, I don't know whether you have fully read all the comments and not just my last one. What has to be fixed by the NTP developers is just 1 point, However, there are others (e.g. using ntpd with -g rather than running ntpdate before starting ntpd) which has to fe fixed in the openSUSE/Novell rc script. So I think "Wontfix" is not the correct status for this since changes have to be made by you folks. Martin Burnicki -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.