Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
On Fri, 2006-12-15 at 15:18 +0100, Tore Anderson wrote: * Scott James Remnant I'd actually argue that you wouldn't want to forcibly change the clock once the first service is *starting*. As soon as you have at least one service running, it's arguably dangerous to slew the clock, and instead we should always step it from there on. Say what?! I hope you've just mixed up the terms here... slew - adjtime() - safe, clock will never leap step - settimeofday() - unsafe, clock will leap [back in time] I'll read the rest of your email assuming you exchanged those two. It's entirely probable ;-) Step to me implies taking small steps, whereas slew implies sliding the clock the entire way. Not the most unambiguous of terms g We think it's a bug in our current install; but one that is less than the previous bug of the clock being not changed at all. Debian certainly shouldn't follow suit, unless they're also happy to have an open bug that the clock is slewed whenever a network interface comes up. I actually submitted a bug to Launchpad about this and had it closed because it was allegedly fixed in the latest release. I didn't verify that myself, though... Maybe I should. I didn't find an open bug about it either. Do you have a link? It looks like a community member closed it in error, I have reopened the bug. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
* Scott James Remnant I'd actually argue that you wouldn't want to forcibly change the clock once the first service is *starting*. As soon as you have at least one service running, it's arguably dangerous to slew the clock, and instead we should always step it from there on. Say what?! I hope you've just mixed up the terms here... slew - adjtime() - safe, clock will never leap step - settimeofday() - unsafe, clock will leap [back in time] I'll read the rest of your email assuming you exchanged those two. If ntpdate is lucky enough to get run before the first service is starting, there's no real harm in slewing it. Yes. That is exactly the role of the ntpdate program. Get the clock into a reasonably correct state before services have begun starting, and ntpd will take it from there and keep it in sync. Without the initial ntpdate call you risk that ntpd will step after five minutes of uptime, because ntpd won't do anything at all before it has finished electing a syspeer and so on, and that takes a few minutes. In those minutes a lot of services have probably have started, and when ntpd finally realises it wants to step, and does, Bad Things might happen. Therefore I want both ntpdate and ntpd in a server. The trick is weighing up the odds; if it's slewed, it can harm servers; but if it's stepped, desktop users will complain that their clock is wrong on boot, and takes a long time to get itself right again. Our primary reason for running it at all is dealing with desktops/laptops with broken hardware clocks. Servers will almost certainly be running ntpd if they care about the time. [...] I believe there's a fair amount of resistance to running ntpd in our default installation. What I installed was a server install. I got certainly got ntpdate with the ifup script (can't quite remember if ntpd was there after the install, but I guess not based on what you're writing above). I also agree servers are best served by ntpd, so it is strange to hear there's resistance against including it in the default installation..? Also ntpdate's documentation states pretty clearly it is no replacement for ntpd at all. Desktops are another matter. I care most about the servers, as I've got probably two or three hundred times as many of those than I do desktops, so I know much less about desktops and what the desktop users in general want. :-) That said, I don't think the always step policy you have (i.e. ntpdate -b) is good there either. If you run ntpdate without any arguments it will step, but only if the offset is 128ms. According to its documentation, anyway. Will really a user complain about the clock being wrong when it's way less then a second wrong? (Actually, I see now that the manual page is self-contradictory, it states elsewhere that the step treshold is 0.5 seconds. But I would think that's insignificant anyway.) We think it's a bug in our current install; but one that is less than the previous bug of the clock being not changed at all. Debian certainly shouldn't follow suit, unless they're also happy to have an open bug that the clock is slewed whenever a network interface comes up. I actually submitted a bug to Launchpad about this and had it closed because it was allegedly fixed in the latest release. I didn't verify that myself, though... Maybe I should. I didn't find an open bug about it either. Do you have a link? The udev daemon being started doesn't have any bearing on whether a network interface is up or not; network interfaces come up at their own leisure. It should be run after udev because I would assume it is useless to even attempt it before. If it still was unable to sync the time because it had no connectivity to the NTP server, well, it failed the one shot it did have and that's that. I see no harm in attempting to run ntpdate just as we're switching to the multiuser runlevel, there's nothing to lose from failure and plenty to gain from success. Our plan for feisty is to run ntpdate as an upstart job (an init script in SysV terms), the state in which it can be run defined as a point after a network interface has come up, but before the boot sequence has finished. If someone needs a clock syncing afterwards, we can either require ntpd; or use -B. This sounds very good to me, it would certainly take ntpdate off my blacklist. :-) Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
Matt's asked me to jump in here to explain the Ubuntu changes, and our long-term plan for such thing; as there seems to be a little confusion and/or argument on this topic. On Fri, 5 May 2006 15:17:53 +0200, Ingo Oeser wrote: The proposed solution of using /etc/networking/if-up.d/ works without any problem for most of your users. Actually unbuntu Dapper Drake is just doing it this way and I never had any problems. We fixed it for our customers the same way. Our reason for moving this to an if-up.d script is because we're increasingly relying on udev to drive the hardware parts of our boot sequence; this meant that there was no point in the SysV boot sequence where networking was up, so no point to run the ntpdate script. Moving to an if-up.d script meant that the clock would be adjusted during boot when the each ethernet card came up; the first not being sufficient as that one might not actually get an IP. This isn't ideal either, as now ntpdate gets run every time you fiddle with an interface. Our preferred solution is to use upstart to manage the ntpdate task, and don't run it once it has succeeded at least once. On Tue, 12 Dec 2006 08:41:12 +0100, Tore Anderson wrote: I know. Maybe I should have been clearer though, what I'm objecting to is primarily the suggestion to mimic the way Ubuntu does it, as they invoke ntpdate with the -b parameter in the if-up.d script, ensuring that the clock will _always_ leap. We use -b because it was what was suggested in the manual page: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. The if-up.d ntpdate script is intended to set the clock at boot time, once the first interface with a reachable ntp server has come up. If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. That's what we're trying to do with the ntpdate script. On Wed, 13 Dec 2006 12:01:36 +0100, Tore Anderson wrote: Ranked in order of preference (as defaults, at least): 1) No gratuitous clock adjustments whatsoever (no if-up.d script) 2) No gratuitous clock stepping whatsoever (use of -B) 3) No gratituous clock stepping unless large offset (default ntpdate) 4) Gratituous clock stepping (use of -b) Ubuntu went with #4 for their Dapper release. Given the above, how would you recommend we sync the clock during boot if no clock adjustments would be preferred? Or are you referring specifically to additional clock adjustments after the first one has been made? Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
* Scott James Remnant Matt's asked me to jump in here to explain the Ubuntu changes, and our long-term plan for such thing; as there seems to be a little confusion and/or argument on this topic. Thanks, I appreciate it. Our reason for moving this to an if-up.d script is because we're increasingly relying on udev to drive the hardware parts of our boot sequence; this meant that there was no point in the SysV boot sequence where networking was up, so no point to run the ntpdate script. Moving to an if-up.d script meant that the clock would be adjusted during boot when the each ethernet card came up; the first not being sufficient as that one might not actually get an IP. I know, but see below for comments. This isn't ideal either, as now ntpdate gets run every time you fiddle with an interface. Our preferred solution is to use upstart to manage the ntpdate task, and don't run it once it has succeeded at least once. I'm not familiar with upstart, I'm afraid, so I can't comment on that. We use -b because it was what was suggested in the manual page: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. The if-up.d ntpdate script is intended to set the clock at boot time, once the first interface with a reachable ntp server has come up. But right now it does not check if any of this is true, which is my main grief here. When the services are done being started (and I think you'll have to assume they do during bootup), it is not safe to step the clock. I think it would be reasonable to assume that this is a concern primarily for server systems that are probably always connected anyway, and thus it would be okay to step the clock later if there was no network at boot (even though this can cause trouble for desktop systems too in some cases, see #364288 for an example). In any case, though, it should not be stepped unless deemed necessary by ntpd[ate] because of a large offset. So if there's a chance of ntpdate being run after bootup, it shouldn't use -b. Default behaviour is okay. I've cooled down a bit now, so I'll moderate myself a bit about demanding -B. :-) * Tore Anderson If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. * Scott James Remnant That's what we're trying to do with the ntpdate script. My opinion is that ntpd is better used for this. When I run ntpd, I expect it to do so if necessary. When I run ifup I expect it to do just that - bring an interface up. Not meddle around with system time, or do any other things unrelated to bringing the interface up. I'm a sysadmin. I don't like surprises. Having my clock stepped on ifup is definetively a surprise, and a nasty one too (offlined half our office). Besides, using ntpd for this would handle the situation where a route to the NTP server is provided by something else than ifupdown, such as a routing service (my case), a PPP[oE] daemon (common xDSL/GSM setups here in Norway at least), and probably other situations too. Finally, ntpd is more accurate than ntpdate - at least it says so in the manual page. Given the above, how would you recommend we sync the clock during boot if no clock adjustments would be preferred? Note gratuitous. I realise that's a matter of personal opinion, but I agree both with you and ntpdate's manual page that stepping on bootup is fine. On the other hand, I think stepping at an arbitrary time after the system is up and running is just asking for trouble, at least for production systems (and again, it might be for desktops too). If I understand you correctly you/Ubuntu think this is an acceptable trade- off and I obviously disagree with you on that. So my recommendation would be to call ntpdate on bootup after udev was started (maybe using Required-Start: $network instead if that's working). If it failed, oh well, start ntpd -g anyway and it'll synchronise when/if the time server becomes reachable at some later point. And most importantly - it will not step unless it feels it needs to do so because of a large offset, and paranoid me, running services I know depend on clock sanity, can add -x to the the ntp- server init script and be safe no stepping will occur after initial boot. If you insist on coupling this to ifup, though: Check to see if the ifup is related to time server reachability at all (in my case it wasn't, which made the whole ordeal feel even more pointless). In pre-up.d do ip route get time server, see if there's already a route there, and if so just skip syncing (or at least, drop -b) in post-up.d. Also you could make the script see if /etc/nologin is present, if not, it's likely not running at system bootup, skip
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
On Thu, 2006-12-14 at 13:07 +0100, Tore Anderson wrote: * Scott James Remnant We use -b because it was what was suggested in the manual page: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. The if-up.d ntpdate script is intended to set the clock at boot time, once the first interface with a reachable ntp server has come up. But right now it does not check if any of this is true, which is my main grief here. When the services are done being started (and I think you'll have to assume they do during bootup), it is not safe to step the clock. That is true, in practice this hasn't caused us many problems; but it is noted as a bug we need to fix. One of the principal differences between Debian and Ubuntu is that we don't have the luxury of a long release cycle, so sometimes the immediate bug is fixed leaving another lesser bug in place to be fixed in a later release. I'd actually argue that you wouldn't want to forcibly change the clock once the first service is *starting*. As soon as you have at least one service running, it's arguably dangerous to slew the clock, and instead we should always step it from there on. If ntpdate is lucky enough to get run before the first service is starting, there's no real harm in slewing it. The trick is weighing up the odds; if it's slewed, it can harm servers; but if it's stepped, desktop users will complain that their clock is wrong on boot, and takes a long time to get itself right again. Our primary reason for running it at all is dealing with desktops/laptops with broken hardware clocks. Servers will almost certainly be running ntpd if they care about the time. Given the above, how would you recommend we sync the clock during boot if no clock adjustments would be preferred? Note gratuitous. I realise that's a matter of personal opinion, but I agree both with you and ntpdate's manual page that stepping on bootup is fine. On the other hand, I think stepping at an arbitrary time after the system is up and running is just asking for trouble, at least for production systems (and again, it might be for desktops too). If I understand you correctly you/Ubuntu think this is an acceptable trade- off and I obviously disagree with you on that. We think it's a bug in our current install; but one that is less than the previous bug of the clock being not changed at all. Debian certainly shouldn't follow suit, unless they're also happy to have an open bug that the clock is slewed whenever a network interface comes up. So my recommendation would be to call ntpdate on bootup after udev was started (maybe using Required-Start: $network instead if that's working). The udev daemon being started doesn't have any bearing on whether a network interface is up or not; network interfaces come up at their own leisure. I believe there's a fair amount of resistance to running ntpd in our default installation. If you insist on coupling this to ifup, though: Our plan for feisty is to run ntpdate as an upstart job (an init script in SysV terms), the state in which it can be run defined as a point after a network interface has come up, but before the boot sequence has finished. If someone needs a clock syncing afterwards, we can either require ntpd; or use -B. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
