Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
Il 07/12/2011 08:30, Harlan Stenn ha scritto: If anybody knows of any *good* reasons to set the clock before starting ntpd, please speak up. Indeed! It is very handy to set the clock directly on system startup (eg. when the external clock is lacking proper battery). I've still got a bunch of system using it. Oh, and of course its very handy for diagnostics. I'm not saying one should not set the clock on system startup. I'm saying I'm not aware of good reasons to set the clock before starting ntpd at system startup. I still use ntpdate -q as a debugging tool. But I have another case, as well. I had a case at $PREVIOUS_EMPLOYER where we had to do exactly that, or more precisely: stop ntpd, run ntpdate, then start ntpd again. We had a few faulty servers that, for some reason, kept setting the clock one or two hours backwards, depending if we had DST or not[*]. Something was happening in the line that the system rebooted/started with proper time and timezone, then read the UTC time from the hardware clock as it was local time, and set it on the system. When ntpd started, it aborted since the machine appeared way off than the tolerated amount. Of course we could dig down into the hairy configuration files of these boxes in order to open a case to either the hardware vendor, or to the distribution vendor. But we were pretty understaffed at the time; plus, keeping that server offline for the few hours needed to debug it was not an option, and we ended up with that patchy workaround. That is why I'd happily keep ntpdate... Ciao -- bronto [*] I am not going to tell which brand the machines were, and which Linux distro they were running: I don't want to go into an endless, useless flame regarding bad hardware and bad distros. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
Marco wrote: Il 07/12/2011 08:30, Harlan Stenn ha scritto: If anybody knows of any *good* reasons to set the clock before starting ntpd, please speak up. Indeed! It is very handy to set the clock directly on system startup (eg. when the external clock is lacking proper battery). I've still got a bunch of system using it. ntpd ... -g ... will work in this case. There is no need to set the time before running ntpd handle the case of a bad CMOS battery. Oh, and of course its very handy for diagnostics. ntpd and sntp should have at least the same level of diagnostic ability. If not, please open a bug report. I'm not saying one should not set the clock on system startup. I'm saying I'm not aware of good reasons to set the clock before starting ntpd at system startup. I still use ntpdate -q as a debugging tool. Are the diagnostic capablilties of sntp or ntpd lacking in any way? But I have another case, as well. I had a case at $PREVIOUS_EMPLOYER where we had to do exactly that, or more precisely: stop ntpd, run ntpdate, then start ntpd again. We had a few faulty servers that, for some reason, kept setting the clock one or two hours backwards, depending if we had DST or not[*]. Something was happening in the line that the system rebooted/started with proper time and timezone, then read the UTC time from the hardware clock as it was local time, and set it on the system. When ntpd started, it aborted since the machine appeared way off than the tolerated amount. Then you were not using the -g flag to ntpd. Use the -g flag and you will not need to set the time before running ntpd. If the time was being reset *after* ntpd was started then you have a different problem and that bug is not with ntpd. In this case: - the -g option is still what you want - you should report the problem upstream (hardware or distribution vendor) Also note that in this case things like dovecot or database servers will complain loudly and probably shut down, because they require monotonic (only forward-moving) time. If you are running those apps they will need to be restarted as well. Of course we could dig down into the hairy configuration files of these boxes in order to open a case to either the hardware vendor, or to the distribution vendor. But we were pretty understaffed at the time; plus, keeping that server offline for the few hours needed to debug it was not an option, and we ended up with that patchy workaround. That is why I'd happily keep ntpdate... And there will be a shell script called ntpdate that will do the right thing (somebody will have to decide if the local policy for the script is set the time ASAP or set the time Well), but again, I'm still not seeing that this is a *necessary* step. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
If ntp can do everything ntpdate can, why not make it a multi-call(?) program (like busybox)? ln -s ntpd ntpdate, and it does what ntpdate does now when called as ntpdate. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
Enrico wrote: * Harlan Stenn st...@ntp.org wrote: Just to be clear, there *used* to be some reasons to set the clock before starting ntpd. In general, there is no need to do this anymore and I have not heard any good reasons it should still be needed. If anybody knows of any *good* reasons to set the clock before starting ntpd, please speak up. Indeed! It is very handy to set the clock directly on system startup (eg. when the external clock is lacking proper battery). I've still got a bunch of system using it. Oh, and of course its very handy for diagnostics. I'm not saying one should not set the clock on system startup. I'm saying I'm not aware of good reasons to set the clock before starting ntpd at system startup. Again, from what I have seen, BCP (Best Current Practice) is to start ntpd as early as possible in the boot sequence, and then as late as possible in the boot sequence run something like ntp-wait before starting time-sensitive startup-processes and opening the system to general use. With a good drift file and a proper ntp.conf file, ntpd will have the clock fully sync'd in about 11 seconds' time. If ntpd should step the time during this startup phase, it will log to syslog and to utmp/wtmp (as appropriate). Debugging based on log timestamps during startup is pretty easy. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
On 07/17/11 15:57, Harlan Stenn wrote: Dave Hart wrote: 2) One-shot clock synchronization, such as before starting step-phobic daemons. In this role, there are a plethora of alternatives, which I will cover below. Just to be clear, there *used* to be some reasons to set the clock before starting ntpd. In general, there is no need to do this anymore and I have not heard any good reasons it should still be needed. If anybody knows of any *good* reasons to set the clock before starting ntpd, please speak up. How about because of bug 1044? -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
On Jul 17, 2011, at 1:57 PM, Harlan Stenn wrote: Dave Hart wrote: After many years of deprecation while still shipping, ntpdate's days as a separate C program are numbered. I want to review alternatives and suggest next steps. First, though, a quick review of why ntpdate is deprecated and will be removed. ntpdate serves two primary purposes today: 1) A diagnostic tool, particularly to help troubleshoot connectivity problems such as those introduced by firewalls. In this role, 4.2.7's sntp provides equivalent capability, including the ability to send queries from the reserved NTP UDP port 123. 2) One-shot clock synchronization, such as before starting step-phobic daemons. In this role, there are a plethora of alternatives, which I will cover below. Just to be clear, there *used* to be some reasons to set the clock before starting ntpd. In general, there is no need to do this anymore and I have not heard any good reasons it should still be needed. If anybody knows of any *good* reasons to set the clock before starting ntpd, please speak up. ntpdate was used to get sub-second synchronization at the cost of about a second of delay in startup. ntpd would take a lot longer to do this, and would have problems with steps. Most daemons hate it when time jumps too much, so this was a good compromise. Does ntpd still dial in the frequency error before doing the phase shift that's patently obvious at startup? If so, then there's still a need for ntpdate. ntpd would also used to start asynchronously, meaning that it was a crap shoot if your daemons would see a a big time-step or not after they started. If these problems have been corrected completely, then maybe ntpdate can be killed. Otherwise, there's still a need for it. Warner ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
On Sun, Jul 17, 2011 at 12:57:06PM -0700, Harlan Stenn wrote: Just to be clear, there *used* to be some reasons to set the clock before starting ntpd. In general, there is no need to do this anymore and I have not heard any good reasons it should still be needed. If anybody knows of any *good* reasons to set the clock before starting ntpd, please speak up. With the -x option (or any larger tinker step) setting the clock before starting ntpd is useful to avoid possibly very long initial offset correction. That wouldn't be needed if ntpd had an option to always step on start. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
Dave Hart wrote: After many years of deprecation while still shipping, ntpdate's days as a separate C program are numbered. I want to review alternatives and suggest next steps. First, though, a quick review of why ntpdate is deprecated and will be removed. ntpdate serves two primary purposes today: 1) A diagnostic tool, particularly to help troubleshoot connectivity problems such as those introduced by firewalls. In this role, 4.2.7's sntp provides equivalent capability, including the ability to send queries from the reserved NTP UDP port 123. 2) One-shot clock synchronization, such as before starting step-phobic daemons. In this role, there are a plethora of alternatives, which I will cover below. Just to be clear, there *used* to be some reasons to set the clock before starting ntpd. In general, there is no need to do this anymore and I have not heard any good reasons it should still be needed. If anybody knows of any *good* reasons to set the clock before starting ntpd, please speak up. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [ntp:hackers] ntpdate removal is coming
Warner wrote: On Jul 17, 2011, at 1:57 PM, Harlan Stenn wrote: Dave Hart wrote: ... 2) One-shot clock synchronization, such as before starting step-phobic daemons. In this role, there are a plethora of alternatives, which I will cover below. Just to be clear, there *used* to be some reasons to set the clock before starting ntpd. In general, there is no need to do this anymore and I have not heard any good reasons it should still be needed. If anybody knows of any *good* reasons to set the clock before starting ntpd, please speak up. ntpdate was used to get sub-second synchronization at the cost of about a second of delay in startup. But you were not getting *synchronization*, you were just getting the time set. Synchronization requires knowledge of frequency correction, too. ntpd would take a lot longer to do this, and would have problems with steps. Right, and the steps problem was resolved Years ago, as I recall. Originally, ntpd and ntpdate used the same algorithms for initial clock selection, so there goes the how long it took argument. More below... Most daemons hate it when time jumps too much, so this was a good compromise. OK, and this is before we had sntp, ntpd -gq, or ntp-wait. Does ntpd still dial in the frequency error before doing the phase shift that's patently obvious at startup? I'm not exactly sure what you mean. And therefore... If so, then there's still a need for ntpdate. Sorry, since I don't know what you meant above I don't see your conclusion here. But more below... ntpd would also used to start asynchronously, meaning that it was a crap shoot if your daemons would see a a big time-step or not after they started. That's why we have ntp-wait, and the option Dave Hart described. If these problems have been corrected completely, then maybe ntpdate can be killed. Otherwise, there's still a need for it. I believe the problems you have described are in the past. ntpdate was/is broken, and will not be fixed. Our new tools seem to offer solutions for the identified use cases. I understand that some folks will want to keep something called ntpdate around for their own reasons. Please see http://support.ntp.org/Dev/DeprecatingNtpdate for more discussion about all of this. Also see http://support.ntp.org/Support/StartingNTP4 . To summarize a bit, if you care enough to run NTP, you either care a Little, in which case you can just periodically run sntp from cron, or you care More, in which case you run ntpd. If you care enough to run ntpd, then you can either run it somewhere in between badly or well. For the sake of this discussion, I'm gonna shoot for the well case because that seems to make the most sense. There are plenty of ways to run ntpd badly (or at least not well). So, for this situation: 1) There is still no demonstrated need to set the clock before starting ntpd. If you care about stable time, ntpd will need some time to make sure things are running smoothly. Start ntpd as early as possible in the boot sequence. If you have time-sensitive processes, start everything else first, then run ntp-wait and then fire off your time-sensitive processes. If you *insist* on setting the clock before starting ntpd, that's fine, but I submit this merely adds a bit of delay to your startup time and does nothing else of *real value*. If you follow our documented BCP, you'll be using 'iburst' and you'll (most always) have a good drift file. Starting ntpd from here (with -gN if you care a lot, or -g if you care a bit less) means your clock will be stable (correct time with no reason to expect a 'step') in about 11 second's time. 2) As time passed, there became 2 groups of folks using ntpdate, those who wanted it to set the time well and those who wanted the time set quickly. Ntpdate has been losing the ability to set the time well, but ntpd -gq can set the time once, well. sntp does a better job of setting the time once quickly. ntpd can set the time well and keep the time right. We will provide an ntpdate script, and somewhere, somebody is going to have to decide if the default case is to set the time well, or set the time quickly. We will certainly provide the mechanism(s) to handle either of these cases, and we *can* provide a default policy (fast, well, or error - choose 'fast' or 'well'). My point here is that we had and old way and we have a new way. They are different. The new way seems to give us all of the functionality we have wanted, with much better control. To take advantage of this, use it properly. Do not expect to get good results from what we used to do. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
