Comment 15 for bug 114505

@feisty,

If your DHCP server isn't providing NTP servers then DHCP should have nothing to do with NTP.
"/etc/rcS.d/S40networking" should have the NIC's up and configured long before "/etc/rc[2345].d/S23ntp" tries to start NTP.

Does you modem do 'lazy connects'?
I'm wondering if the DNS queries from NTP are the first thing the modem hears, causing it to connect.
If the modem takes too long to connect then the DNS queries will fail and NTP won't start.
Could you add a few IP addresses (rather than FQDN's) to your ntp.conf file?
What does "ntpq -p" say?

@Phillipp
"Would it hurt to restart ntp whenever a network interface comes up?"
Yes, but not much.
NTP builds up information on remote servers and local clock drift. This is lost on restart, meaning NTP won't work as well as it could (i.e. it'll take longer to sync, and even longer to tweak the local clock frequency).
Arguably this is not a big problem for most situations where all you want is accuracy within a few seconds (in which case "ntpdate" may be a better choice anyway).

The polling interval NTP uses tends to increase as time goes on (it starts at 2^6 seconds (roughly once a minute), I've seen it as high as 2^16 (roughly every 18 hours)).
Re-starting NTP will mean a shorter polling interval and more load on the servers (especially if you use "iburst").

I think the thinking behind the "exit 0" in "/etc/network/if-up.d/ntp" is that, if your network address changes, it was probably DHCP that changed it and DHCP should be responsible for re-starting NTP.