[Bug 90267] Re: ntp starts before the network is up in feisty
I just tried n-m 0.6.4-ubuntu5. Same problem. Same reaction, an immediate apt-get remove network-manager to restore working behaviour. -- ntp starts before the network is up in feisty https://bugs.launchpad.net/bugs/90267 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
@James: I have just connected to my home wireless (on reboot) and... NTP came in correctly, after the wireless was connected! I am not sure what to attribute this to yet, but I can state I am running the stock feisty, up-to-date. Would you be able to try it? I do not know about wired interfaces (I have one, but I will have to grab the emergency cable, which is very well and safely stored at an (right now) unknown location -- in other words, I lost it). This sort of surprised me, since I have seen no developer activity here. -- ntp starts before the network is up in feisty https://bugs.launchpad.net/bugs/90267 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
My prefer fix is still apt-get remove network-manager I just installed network-manager 0.6.4-6ubuntu4 and it still starts ntpd before the network is up. I apt-get remove network-manager and ntp works properly again. With n-m not installed the network gets started THEN any network services are run. These days I apt-get remove network-manager on any new install to avoid this problem. -- ntp starts before the network is up in feisty https://bugs.launchpad.net/bugs/90267 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
James, with the changes that Tollef made for n-m, do you still experience this problem? -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
Still experiencing the problem. The following still shows ntp starting before the network is up when using n-m. Mar 16 10:54:46 wilma NetworkManager: information^IDHCP daemon state is now 1 (starting) for interface eth0 Mar 16 10:54:48 wilma rpc.statd[4932]: Version 1.0.10 Starting Mar 16 10:54:49 wilma ntpd[4951]: ntpd [EMAIL PROTECTED] Wed Mar 7 20:43:30 UTC 2007 (1) Mar 16 10:54:49 wilma ntpd[4952]: precision = 1.000 usec Mar 16 10:54:49 wilma ntpd[4952]: Listening on interface wildcard, 0.0.0.0#123 Disabled Mar 16 10:54:49 wilma ntpd[4952]: Listening on interface wildcard, ::#123 Disabled Mar 16 10:54:49 wilma ntpd[4952]: Listening on interface lo, ::1#123 Enabled Mar 16 10:54:49 wilma ntpd[4952]: Listening on interface lo, 127.0.0.1#123 Enabled Mar 16 10:54:49 wilma ntpd[4952]: kernel time sync status 0040 Mar 16 10:54:49 wilma hcid[4969]: Bluetooth HCI daemon Mar 16 10:54:49 wilma NetworkManager: debug info^I[1174006489.245454] nm_hal_device_added (): New device add ed (hal udi is '/org/freedesktop/Hal/devices/platform_bluetooth'). Mar 16 10:54:49 wilma hcid[4969]: Starting SDP server Mar 16 10:54:49 wilma ntpd[4952]: frequency initialized -8.412 PPM from /var/lib/ntp/ntp.drift Mar 16 10:54:50 wilma dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Mar 16 10:54:50 wilma dhclient: DHCPACK from 172.16.31.1 Mar 16 10:54:50 wilma ntpd[4952]: sendto(172.16.31.201) (fd=16): Network is unreachable Mar 16 10:54:50 wilma avahi-daemon[4657]: Joining mDNS multicast group on interface eth0.IPv4 with address 172 .16.31.3. Mar 16 10:54:50 wilma avahi-daemon[4657]: New relevant interface eth0.IPv4 for mDNS. Mar 16 10:54:50 wilma avahi-daemon[4657]: Registering new address record for 172.16.31.3 on eth0.IPv4. Mar 16 10:54:50 wilma avahi-daemon[4657]: Withdrawing address record for 172.16.31.3 on eth0. Mar 16 10:54:50 wilma avahi-daemon[4657]: Leaving mDNS multicast group on interface eth0.IPv4 with address 172 .16.31.3. Mar 16 10:54:50 wilma avahi-daemon[4657]: Interface eth0.IPv4 no longer relevant for mDNS. Mar 16 10:54:50 wilma avahi-daemon[4657]: Joining mDNS multicast group on interface eth0.IPv4 with address 172 .16.31.3. Mar 16 10:54:50 wilma avahi-daemon[4657]: New relevant interface eth0.IPv4 for mDNS. Mar 16 10:54:50 wilma avahi-daemon[4657]: Registering new address record for 172.16.31.3 on eth0.IPv4. Mar 16 10:54:50 wilma NetworkManager: information^IDHCP daemon state is now 4 (reboot) for interface eth0 Mar 16 10:54:50 wilma NetworkManager: information^IActivation (eth0) Stage 4 of 5 (IP Configure Get) schedul ed... Mar 16 10:54:50 wilma NetworkManager: information^IActivation (eth0) Stage 4 of 5 (IP Configure Get) started ... Mar 16 10:54:50 wilma NetworkManager: information^IRetrieved the following IP4 configuration from the DHCP d aemon: Mar 16 10:54:50 wilma NetworkManager: information^I address 172.16.31.3 Mar 16 10:54:50 wilma NetworkManager: information^I netmask 255.255.255.0 Mar 16 10:54:50 wilma NetworkManager: information^I broadcast 172.16.31.255 Mar 16 10:54:50 wilma NetworkManager: information^I gateway 172.16.31.254 Mar 16 10:54:50 wilma NetworkManager: information^I nameserver 172.16.31.1 Mar 16 10:54:50 wilma NetworkManager: information^I domain name 'bedrock' Just found a new tip for the day. When using ssh to connect to a remote machine don't remove n-m. When it goes it takes the network with it. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
I have asked for opinions from the assignee for bug # 82335 (it might need to be considered for the n-m work there). -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
Between that other thread and your comments I was hoping network manager might be optional. I removed it with apt-get remove network-manager Getting sane behaviour. Network services being started after the network is up. Ntp working as expected. Servers specified by IP being added. Servers specified by name being added. Every thing was working fine. Did an apt-get upgrade. Whoops, something in the upgrade pulled network-manager back in and back to the broken behaviour. I am guessing it was kubuntu-desktop. It was a freshly installed machine so a big update. Removing n-m now brings it up to 4 work arounds I have just to get ntp working. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
That comment is a good argument for leaving 'exit 0' in /etc/network/if- up/ntp when the move is made to ntp 4.2.4. I have already been playing with ntp 4.2.4 and seen the interface scanning in action. I think this is a solution for a different problem not the problem I am having. What you said covers having a properly running ntp then having an interface change. My problem is ntp not starting up properly. Not part of this bug but ntp 4.2.4 has it's own problems starting before the network is up when the computer is booting. 1. Starts before eth0 is up. Will refuse to add servers even by ip because there is no network to the address. 2. Can end up starting at the same time as ntpdate. If ntpdate gets port 123 first then ntp will fail to bind to port 123 and exit. 3. Have seen ntp start with eth0 up just in time so some servers can get added by ip. Not all servers listed by ip get added. 4. Still can not resolve any fqdn. The computer that I have been pasting the log from has an ip of 172.16.31.3. The ip does not change. The computer gets it's ip via dhcp but is effectively a static ip as the ip is mapped to the mac address. My stratum 1 is 172.16.31.201. ntp 4.2.2p4 When run before eth0 is up ntp can not bind to eth0. The server 172.16.31.201 can be added by ip but not by fqdn. 172.16.31.3 can send packets to 172.16.31.201 but because ntp is not bound to eth0 any replies will be ignored. ntp 4.2.4 When run before eth0 is up ntp can not bind to eth0. Ntp refuses to add server 172.16.31.201 because eth0:172.16.31.3 is not up yet. Says Cannot find existing interface for address 172.16.31.201. This version of ntp seems to pick up eth0 when it does it's scan ok but this does not do much good because no servers are defined. If I restart ntp after the machines have booted then ntp will work properly everytime. Either version. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
more digging in required (thanks, Matt, your comments, and of those in #ubuntu-bugs helped a lot). I am always amazed by the depth of my ignorance... /etc/network/if-(up|down|post-down|pre-up).d scripts are the responsibility of each package: NTP, NTPdate, and others. These scripts are executed whenever the action (reflected in the directory name) is executed. So, it is not a n-m issue here. I was wrong. Nor it is NTP (not sure), or upstart. Will have to figure out. Anyway: a summary, so far: 1. as provided, ubuntu has the /etc/network/if-up.d/ntp script disabled. As a result, connections purely managed from n-m do not get ntp service (so it seems). Why? 2. Although not hurting, ntp and ntpdate got installed; ntpdate cannot run if ntpd is running, so having both in *may* not be necessary. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
There is a comment in http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=399905 about this issue, and it refers to an upstream bug (https://ntp.isc.org/bugs/show_bug.cgi?id=51) where it is strongly recommended not to bounce ntpd on I/F status changes. This is (probably) the reason why /etc/network/ifup.d/ntp is disabled by default: there is a chance the clock will get wildly inaccurate, and the carefully maintained statistics will be lost. Per the comments on https://ntp.isc.org/bugs/show_bug.cgi?id=772 upstream it seems that ntp, once it gives up on root, cannot change the IP (which is correct behaviour, since port 123 is privileged). The fix is either to run NTP as root, or to run Linux with capabilities (so that the correct capability can be given to the 'ntp' userid). Anyway, the fix is on 4.2.4, which has not yet been packaged by Debian. So it seems there is no real solution right now. Perhaps one option is not to install ntpd on machines that dynamically and/or frequently change the IP address -- instead, use ntpdate. On the other hand, ntpdate is less reliable (see 'man ntpdate' for example), and it is recommended to be run every hour in order to minimise the chance of large clock changes. Still digging. ** Changed in: network-manager (Ubuntu) Status: Confirmed = Needs Info -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
No wireless here. As a work around I put a sleep 5 at the top of /etc/init.d/ntp. This delays the starting of ntp long enough that I now have a working ntp. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
This is interesting. NTP should, by default, bind to all local interfaces, on UDP, and should be able to recover by itself. Can you attach a 'grep ntp /var/log/daemon.log' piece here, long enough to show the system startup some few hours of run? ** Changed in: network-manager (Ubuntu) Importance: Undecided = Medium -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
Ntp seems to go out of it's way to not do a wildcard bind to port 123. It is only binding to port 123 for each interface. If the interface is not up it does not get bound to. This is from starting ntp after eth0 is up. Mar 9 06:36:46 fred ntpd[2276]: Listening on interface wildcard, 0.0.0.0#123 Disabled Mar 9 06:36:46 fred ntpd[2276]: Listening on interface lo, 127.0.0.1#123 Enabled Mar 9 06:36:46 fred ntpd[2276]: Listening on interface eth0, 172.16.31.2#123 Enabled I started another machine and let it go for 30 minutes and no difference. Ntp does not change. Mar 9 07:52:34 wilma ntpd[5034]: ntpd [EMAIL PROTECTED] Wed Mar 7 20:43:30 UTC 2007 (1) Mar 9 07:52:34 wilma ntpd[5035]: precision = 1.000 usec Mar 9 07:52:34 wilma ntpd[5035]: Listening on interface wildcard, 0.0.0.0#123 Disabled Mar 9 07:52:34 wilma ntpd[5035]: Listening on interface wildcard, ::#123 Disabled Mar 9 07:52:34 wilma ntpd[5035]: Listening on interface lo, ::1#123 Enabled Mar 9 07:52:34 wilma ntpd[5035]: Listening on interface lo, 127.0.0.1#123 Enabled Mar 9 07:52:34 wilma ntpd[5035]: kernel time sync status 0040 Mar 9 07:52:34 wilma ntpd[5035]: frequency initialized -8.102 PPM from /var/lib/ntp/ntp.drift By 8:22 no change. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
I just tried ntp 4.2.4 which has code to scan for new interface every 5 minutes. That will bind to eth0 sometime after eth0 is brought up. There is another problem with ntp starting before eth0 is up. When the server lines in ntp.conf use hostnames they can not be resolved. So if ntp does eventually bind to eth0 it still won't work. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
I will look more closely at what is going on, James. On your last comment: yes, this is a known, huh, issue/limitation: if there is no name server resolution available, then fully-qualified hostnames (like ntp.ubuntu.com, or pool.ntp.org, etc) will not get resolved -- after all, they do depend on having access to a NS. Usually, when synchronisation is critical, NTP should be set with an IP address, not a FQHN. But, once bound to a working interface, NTP should eventually be able to access a NS, and synchronise. Right now it is starting to look like we have two different issues here: (1) when NTP is installed, network-manager should not call ntpdate; (2) NTP cannot bind to an interface that is not available during startup (this one is a bit more convoluted, methinks: if n-m is the one setting up any, and all network interfaces, then it seems NTP should not be started until n-m successfully brings up such an interface). Do you agree? -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
and... yes indeed. Per chance I had started my laptop with a wireless connection, driven by n-m. Here's the NTP messages for the startup: Mar 8 18:28:00 localhost ntpd[8566]: ntpd [EMAIL PROTECTED] Wed Mar 7 20:43:39 UTC 2007 (1) Mar 8 18:28:00 localhost ntpd[8567]: precision = 1.000 usec Mar 8 18:28:00 localhost ntpd[8567]: Listening on interface wildcard, 0.0.0.0#123 Disabled Mar 8 18:28:00 localhost ntpd[8567]: Listening on interface wildcard, ::#123 Disabled Mar 8 18:28:00 localhost ntpd[8567]: Listening on interface lo, ::1#123 Enabled Mar 8 18:28:00 localhost ntpd[8567]: Listening on interface lo, 127.0.0.1#123 Enabled Mar 8 18:28:00 localhost ntpd[8567]: kernel time sync status 0040 Mar 8 18:28:00 localhost ntpd[8567]: frequency initialized 12.637 PPM from /var/lib/ntp/ntp.drift Mar 8 18:28:00 localhost ntpd[8575]: signal_no_reset: signal 17 had flags 400 Mar 8 18:28:02 localhost ntpd_initres[8575]: host name not found: ntp.ubuntu.com Mar 8 18:28:02 localhost ntpd_initres[8575]: couldn't resolve `ntp.ubuntu.com', giving up on it Mar 8 18:28:02 localhost ntpd_initres[8575]: host name not found: pool.ntp.org Mar 8 18:28:02 localhost ntpd_initres[8575]: couldn't resolve `pool.ntp.org', giving up on it Mar 8 18:33:55 localhost ntpdate[9707]: the NTP socket is in use, exiting Mar 8 20:33:33 localhost ntpd[8567]: ntpd exiting on signal 15 So we have the interfaces disabled, everywhere. NTP is up, but is just wasting CPU cycles and memory. The errors on name resolution are expected, since I do not have a caching NS running on my laptop. Would not help much, anyways :-) So I restarted it, now with the wireless running: Mar 8 20:33:36 localhost ntpd[14447]: ntpd [EMAIL PROTECTED] Wed Mar 7 20:43:39 UTC 2007 (1) Mar 8 20:33:36 localhost ntpd[14448]: precision = 1.000 usec Mar 8 20:33:36 localhost ntpd[14448]: Listening on interface wildcard, 0.0.0.0#123 Disabled Mar 8 20:33:36 localhost ntpd[14448]: Listening on interface wildcard, ::#123 Disabled Mar 8 20:33:36 localhost ntpd[14448]: Listening on interface vmnet8, fe80::250:56ff:fec0:8#123 Enabled Mar 8 20:33:36 localhost ntpd[14448]: Listening on interface lo, ::1#123 Enabled Mar 8 20:33:36 localhost ntpd[14448]: Listening on interface eth1, fe80::290:4bff:feff:c508#123 Enabled Mar 8 20:33:36 localhost ntpd[14448]: Listening on interface lo, 127.0.0.1#123 Enabled Mar 8 20:33:36 localhost ntpd[14448]: Listening on interface eth1, 192.168.1.3#123 Enabled Mar 8 20:33:36 localhost ntpd[14448]: Listening on interface vmnet8, 192.168.54.1#123 Enabled Mar 8 20:33:36 localhost ntpd[14448]: kernel time sync status 0040 Mar 8 20:33:36 localhost ntpd[14448]: frequency initialized 12.637 PPM from /var/lib/ntp/ntp.drift and my wireless interface, eth1, is now being used by NTP. Hum. I will have to munch a bit on this. Your comments will be appreciated. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
ntp ought to be restarted when a new interface is brought up, but for some reason this is disabled by default: mizar:[/etc/network/if-up.d] cat ntp #!/bin/sh # remove (or comment out) the next line if your network addresses change exit 0 case $ADDRFAM in inet*) if [ -x /etc/init.d/ntp ]; then if [ -x `which invoke-rc.d 2/dev/null` ]; then invoke-rc.d ntp restart || exit $? else /etc/init.d/ntp restart || exit $? fi fi ;; esac -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
Hggdh, I agree with your points. I tried commenting out the exit 0 in the script Matt mentions. Ntp works at boot time now. It also gets restarted if I ifdown eth0; ifup eth0. Still have ntpdate being run after ntp has started and it fails because ntp is running. In ntp.conf a mix of server lines using IP and FQDN works fine. Watching the boot process it looks like ntp is being started early on then being restarted after the network is up. -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
** Changed in: network-manager (Ubuntu) Assignee: (unassigned) = Ubuntu Desktop Bugs -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 90267] Re: ntp starts before the network is up in feisty
** Changed in: upstart (Ubuntu) Status: Unconfirmed = Rejected ** Changed in: ntp (Ubuntu) Status: Unconfirmed = Rejected -- ntp starts before the network is up in feisty https://launchpad.net/bugs/90267 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
