There are many reasons one would wnt to trun ntpdate just beore launching ntpd. IF you run NFS, or other time sensitive daemons, haveing a clock that is set properly is a good thing. ntpd works pretty well, but i've found it's best to 'kludge' it with ntpdate *before* launching ntpd. OpenBSD has an option for this. I think other BSDs do as well. Anyway, here are my changes. You will probbably want to clean these up a little bit. But, they work great for me! Create a new file: /etc/conf.d/ntpd contents: # Config file for /etc/init.d/ntpd # Server to use when doing ntpdate kludge before starting ntpd NTPDATESERVER=valid.time.server The updated /etc/init.d/ntpd contents: #!/sbin/runscript # Copyright 1999-2002 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License, v2 or later # Config is in /etc/conf.d/ntpd depend() { need net } checkconfig() { if [ -z "$NTPDATESERVER" ] ; then eerror "You need to setup NTPDATESERVER in /etc/conf.d/ntpd first" return 1 fi } start() { ebegin "Running ntpdate" ntpdate $NTPDATESERVER > /dev/null eend $? ebegin "Starting ntpd" start-stop-daemon --start --quiet --exec /usr/bin/ntpd -- -p /var/run/ntpd.pid eend $? } stop() { ebegin "Stopping ntpd" start-stop-daemon --stop --quiet --pidfile /var/run/ntpd.pid eend $? }
Another solution I thought of, is to skip the ntpdate kludge if you do not have the variable set... that might be a better solution for some? At least those with clocks that don't suck (like me).
Fixed in ntp-4.1.72-r1.
ntpdate is an old program. From the manual... "Disclaimer: The functionality of this program is now available in the ntpd program. See the -q command line option in the ntpd - Network Time Protocol (NTP) daemon page. After a suitable period of mourning, the ntpdate program is to be retired from this distribution" It is not recomended to be used as they intend on removing it, instead you can use the -q option to ntpd, which synchronises your clock and then exits ntpd. If you just use ntpdate to sync your clock just before starting ntpd then you can use the iburst option with server statements in your ntp.conf file, this makes ntpd send 6 burst requests to the time server as soon as it is started. I have submitted an update to do this once before and think it would be better to change it back again. I see no point in using ntpdate if you are going to run ntpd imediatly afterwards and you have specified the iburst option with all your servers. Note: Although ntpdate is faster than ntpd -q, ntpdate is not able to be as accurate as ntpd -q. From the manual ... "Note that the accuracy and reliability of ntpdate depends on the number of servers, the number of polls each time it is run and the interval between runs." Regards -Rob
Those of us on dialup modems and no permanent network connection are now blessed with an extended bootup until this kludge times out. Please remove this asap: 1. ntpdate is to be retired and is no longer reccomended in the ntpd docs 2. the "iburst" keyword is to be preferred 3. considerably extends bootup time if no network connection exists BillK
Donny, this is actually out of my league .. know about ntpd ? Or who we could ask ?
Looks like they're asking that it could/should just be this now: --init-- depend() { need net } start() { ebegin "Starting ntpd" start-stop-daemon --start --quiet --exec /usr/bin/ntpd \ -- -p /var/run/ntpd.pid ${NTPD_OPTS} eend $? } stop() { ebegin "Stopping ntpd" start-stop-daemon --stop --quiet --pidfile /var/run/ntpd.pid eend $? } --conf.d-- # The '-q' option mimics the behaviour of the 'ntpdate' program, # which is to be retired. It causes ntpd to exit just after the # first time the clock is set. You should add the 'iburst' # keyword to the server statements in /etc/ntp.conf before using # this. #NTPD_OPTS="-q" -- actually i just realized that the above doesnt restart ntpd if they wanted to use the -q option ;) so a way to detect if they passed -q and start ntpd again is needed i guess. somebody should test/add that ... im having no luck using ntpd here at all.. im just using rdate -s instead.
Ok, done done and done. Changes should be in ntp-4.1.1b-r2.
the problem with using `ntpd -g -q` is that it doesnt work the same as ntpdate ... i have yet to get ntpd to 'mimic' the functionality of ntpdate like the manual page claims ...
also the timeout issue can be taken care of by launching ntpdate into the background ...
O.K. Well, it worked here when I checked it. But then, I do not use it, and do not see why I want to get it fixed. You fix it, or drop it on somebody else ... I already have too much dropped on me, so sorry. Problem is that nobody can just edit a damn thing if defaults do not work.
rbragg,woodchip: can you guys give me an *exact* command you need to run to mimic ntpdate functionality ? i dont want something out of the manual, i want something you guys have done and know works
please check out -r3 ... this one well allow ppl to use ntpdate if they choose (i do :P) or to utilize ntpd, or not run anything at all
The best equivalent to ntpdate with ntpd is probably ntpd -qg where all servers have the iburst keyword and you have an accurate drift file. But I dont think that is important in this situation. Generally speaking I can see two common ways of using the ntp. 1. you want to periodically update your clock maby using crond once a day or somthing like that.(e.g. you have a dial up/dont have fixed internet connection) 2. you want to have your clock constantly monitored and corrected. ntpdate/ntpd -q is suited to those that fit group 1. My choice would be ntpd -q since it would be more accurate. ntpdate can not change your clock frequency, which in this situation is important if you want to maintain an accurate time untill your next update. Note: That you would probably want to run ntpd for an hour or so before using this method since it takes an hour before ntpd will write a drift file, which is neccisary for correctly setting the clock frequency. The more often you can run ntpd continuously the better basicly. I think that we are trying to configure gentoo for people in group 2. in this situation I think we _should_ assume that when a user turns their machine on. their clock is correct! (maby not to the millisecond/second or even minute, but that's why we want ntpd) If their clock isn't correct then maby they have bigger problems (CMOS battery..?), that need sorting out first. Assuming the clock is correct all we need to do now is run ntpd. If there is no drift file it will spend 15 minutes figuring out your clock frequency error and using that + some clever algorithms it will then try and make your clock super accurate. After an hour it will write the frequency error to your drift file to give it a head start next time you restart ntpd. Running ntpdate (or ntpd -q for that matter) just before it does all that just doesn't seem usefull. It may change your clock for the better, or if your clock was good to start it could change it for the worse, not that either would be particularly significant. I can't see any really bad concequences from running ntpdate/ntpd -qg before starting up ntpd except maby some wasted cpu cycles or an unnecissary jump of your clock (which could __*possibly*__ annoy something that wasn't expecting that time to just dissapear(Though I think this is a very unlikly problem.)) I know the latest revision doesn't assume you want to use ntpdate before running ntpd and infact defaults to doing nothing. The warning + comments seem to imply that you _should_ be using one of ntpdate or ntpd to initialise the clock before using ntpd which isn't true at all.(imho) Removing the initialisation would make the rc script simpler, you wouldn't need the conf.d file and if they do decide to remove ntpdate, then we wont have to change a thing and so it would be a more _correct_ configuration. (imho) If people still wanted to run ntpdate before starting ntpd then isn't it easy enough for them to edit the rc script? Maby even comment out an ntpdate line. Ok that's the end of my rant. Best regards, Rob I hope you all had a happy new year.
the reason its good for ppl who set their clock on boot first and then track it by running ntpd is for ppl (like me) who dual/multi boot ... their other OS's will set their clocks as they will and when you reboot to linux its not uncommon to have your clock off by a few hours i'm sure if you tweak each OS you could get it so that both work together, but its easier this way ... and to be honest i dont know *exactly* how to tweak both so they maintain the same time ...
