during an email conversation with the ntp maintainers about bug 21444, one of them said: > ntpdate is going out; people *should* be able to use ntpd -g or ntpd -q > (?) as a replacement. Failing that, there is sntp. we could get ahead of things and replace ntpdate with 'ntpd -g -q -x'. from the docs at <http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html>: -q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option.
Does ntpd check it's arguments and default to this behavior if argv[0] is 'ntpdate'? Also, ntpdate doesn't require a configuration file whereas ntpd does. ntpdate also outputs a nice adjustment info line when it runs. It's probably all possible, but I don't think it's there quite yet...
the only problem ive had with using `ntpd -q` is that the damn thing has never worked correctly for me :) i wasnt about to add something to portage when i couldnt get it to work properly on my box ... ill try again with 4.1.2 though ...
yeah, 4.1.2 still does it for me ... that is, i cant get ntpd to mimic ntpdate functionality ... so if someone can put together a small howto and post it here i'll be happy to try it out
well, i'll visit this again when someone can provide a solution that works
*** Bug 88279 has been marked as a duplicate of this bug. ***
The following url provides information on this topic: http://www.ntp.org/ntpfaq/NTP-s-config.htm In particular, 6.1. Can't I become happy with ntpdate alone? 6.1.3.2. How can I speed up initial Synchronization? It seems there are two possibilities: 1) add the iburst option to the server command in ntp.conf like this: server pool.ntp.org iburst and use 'ntpd -q'. 2) use 'ntpd -qg' Both works for me, but the former seems the best cause, as SpanKY pointed out, the '-g' option diverges much from ntpdate behaviour.
erm no i think you have that reversed the ntp-client is supposed to set the date regardless of how far off the current system clock is ... thus we want -g
*** Bug 154613 has been marked as a duplicate of this bug. ***
The best way to emulate 'ntpdate' is to use 'ntpd -gq'. The '-g' option allows ntpd to make one clock adjustment that is greater than the 1024 second panic limit. You need this option to allow ntpd to step the clock regardless of how far off it is. The '-q' option causes ntpd to run in the foreground and exit after the clock is set once. You need this to duplicate ntpdate's blocking / single clock set behaviour. 'ntpd -gq' will output a line of information showing how much the clock was stepped: dumpster:~# ntpd -gq ntpd: time slew +0.004382s There is some discussion of this matter at http://ntp.isc.org/bin/view/Dev/DeprecatingNtpdate
*** Bug 403255 has been marked as a duplicate of this bug. ***
Some of the comments in this thread don't make sense to me, reading them ten years later, so my apologies if I'm rehashing something that's already been addressed, but... To quote from http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate : > If you want your system to have accurate time, run ntpd. Start ntpd as > early as possible in the boot sequence. When it returns, process all > of your non-time-sensitive startup processes. If you have services > that need stable time before they begin, at this point run ntp-wait, > and if it returns "success" it is safe to start your time-sensitive > services. > Pretty much anything else will not give you what you want. If you run > sntp or ntpd -gq first, then eventually run ntpd and your other > services, while the time will be set correctly between the time of the > initial correction and when ntpd is restarted nothing is being done to > discipline the clock. In this interim, enough drift could occur that > when ntpd is finally started that ntpd would need to step the clock > back, an operation that is Bad for databases and things like MailDir > filestamps. Far better to just begin with ntpd -g and let ntpd get the > time set, and then while the non-sensitive processes are running, ntpd > is still able to keep the clock disciplined. [...] > It is no longer necessary to set the time before starting ntpd. > Use the -g option to ntpd. The system will need to have the time set > to within 68 years (more or less) before starting ntpd. So, why don't we just make this the default behavior for Gentoo systems with net-misc/ntp installed? Why do we need to use `ntpd -q` or `ntpdate` at all, at least in an rc script? For those who want to sync their time after the system has already booted, they can run `ntpd -gqc /dev/null server1.name.net server2.name.org server3.name.com` as mentioned in the document. Maybe this wasn't there back in 2003 when Luke-Jr said that `ntpdate` doesn't require a config file but `ntp -q` does. In any case, emerging net-misc/ntp (the only package which provides `ntpdate`) already provides the user with /etc/ntp.conf so I'm not sure why `ntp -q` requiring this config file is a problem. Again, sorry if I'm barging in and saying obvious things, but this ticket looks pretty lifeless so I figured it couldn't hurt :)
(In reply to comment #11) some people only want to sync the clock once at boot. maybe it's because their system doesn't have an RTC at all, so the system clock always starts off at the epoch. maybe their overall runtime drift is "good enough", so they don't need ntpd constantly running. there are plenty of valid reasons for having an init.d script purely for setting the clock once at boot and that is all. removal of the ntp-client init.d script is not up for discussion. as for using `ntpd -qg` in place of `ntpdate`, the answer to that has been posted many times: it doesn't matter what the documentation claims if the command doesn't actually work. i screwed around with it many many times and it never worked. you can claim a command is deprecated and you shouldn't use it all you like ... nothing is going to change until reality matches the rhetoric. all that said, i tried running `ntpd -qg` with the latest version and the default configs and it (surprisingly) actually worked. so with that in mind, i don't have a problem changing the default commands used in the conf.d/ntp-client.
(In reply to comment #12) > as for using `ntpd -qg` in place of `ntpdate`, the answer to that has been > posted many times: it doesn't matter what the documentation claims if the > command doesn't actually work. i screwed around with it many many times and > it never worked. you can claim a command is deprecated and you shouldn't > use it all you like ... nothing is going to change until reality matches the > rhetoric. It is impossible to comment on your assertion without detailed information about how you invoked 'ntpd -qg', what what was in your ntp.conf, and the error message you received. All I can say is that 'ntpd -gq' has worked for me since 2003. > all that said, i tried running `ntpd -qg` with the latest version and the > default configs and it (surprisingly) actually worked. so with that in > mind, i don't have a problem changing the default commands used in the > conf.d/ntp-client. sntp (in ntp-dev) is now the recommended replacement for ntpdate.
(In reply to comment #13) > sntp (in ntp-dev) is now the recommended replacement for ntpdate. And this is already provided by Gentoo's net-misc/ntp package, so we can feel free to use it in the ntp-client init script without changing the init script to be owned by a different package, I guess.
(In reply to comment #13) obviously i don't have the logs from 2003-2007, but i'm pretty sure i tried running all the commands documented (and variations thereof) and none of them worked. i remember even trying it every year or so to see if anything changed -- it didn't. the command would either error out or time out or return silently but not actually update the clock because it was too far out of sync (i.e. the -g option lied). but as i said, debating the brokeness of ntp i saw from 4+ years ago isn't useful today. looking at sntp shows another lovely in-flux tool where the options are still changing significantly. the latest version no longer has a syslog option ? and the logging option it does have doesn't work ? -> http://bugs.ntp.org/show_bug.cgi?id=2389 i guess Gentoo will continue to default to ntpdate and i'll look at this again whenever 4.2.8 comes out to see if sntp has improved at all.
Really explains everything in detail,the article is very interesting and effective. https://bit.ly/3rtbWNj
