On Saturday 09 June 2007 23:30:26 Joe Barnett wrote: > Anne Wilson wrote: > > On Saturday 09 June 2007, Gene Heskett wrote: > >> On Saturday 09 June 2007, Joe Barnett wrote: > >>> Anne Wilson wrote: > >>>> On Saturday 09 June 2007, Joe Barnett wrote: > >>>>> Try running "ntpd -gq" at the end of rc.local to sync the clock. > >>>>> Then kick off nptd (with your normal settings) following that. > >>>> > >>>> I'm not sure I understand that - what do you mean by the second > >>>> statement? > >>> > >>> I apologize for the confusion. > >>> > >>> "ntpd -gq" runs the daemon only long enough to sync the clock, then > >>> it quits. Think of ntpdate. > >> > >> Which is exactly what it did the last time I studied that startup script > >> in /etc/init.d. It runs ntpdate once to crash synch the clock, and then > >> runs the ntpd. > >> > >>> Why not just use ntpdate? Good > >>> question. man ntpd indicates that ntpdate is going to be retired at > >>> some point, and that ntpd -q should be used instead. -q seems to > >>> stand for quit (as soon as the clock is adjusted). -g tells ntpd > >>> not to exit with error if the offset is greater than 1000 seconds. > >>> > >>> I am not sure why they want to retire ntpdate as it seems a very > >>> useful tool. Anyway... > >> > >> I agree, however retiring such a usefull tool might be desirable from > >> the standpoint of being replaced by a better way, possibly built into > >> ntpd, but I've not noted any discussion about it. And I'm of course not > >> on a mailing list that would make me privy to that either. I would hope > >> that they would make an attempt at advising the users that there was a > >> change coming first. > >> > >>> Both the stock ntpd and openntpd have features which should bring > >>> the clock to good time as soon as they get a good feed from one or > >>> more of the servers for which they are configured to use. ntpd -gq, > >>> in theory, should not be needed if either ntpd is going to be run as > >>> a daemon. > >>> > >>> That being said, my experience (with both the stock ntpd and > >>> openntpd) is that it is best to do a gross adjustment first (whether > >>> by ntpd -gq, ntpdate, rdate, etc.) *then* start the daemon. That is > >>> why I use two commands to get my ntp stuff going. > >> > >> Which is what the current (fc6 anyway) startup script does. Quite well > >> in fact if the network is available at runtime. In Anne's case, that > >> can't be assumed. Probably because its miss-configured in ways I'm not > >> familiar with since I don't yet use wpa_supplicant, in fact its all done > >> by the network script on my lappy. The WEP key is actually listed in > >> my /etc/sysconfig/network-scripts/ifcfg-wlan0 using the KEY=syntax but I > >> have NDI if the WAP(2) key Anne is using could be similarly defined > >> there or not. > >> > >> It might be worth a try, Anne. > > > > ntpd was attempting to run before wpa_supplicant could join the network. > > I'm torn between re-numbering it and removing it in favour of the two > > commands in rc.local. I think I'll take those commands out again, for a > > trial, and see whether the re-numbering does the trick. > > > > Anne > > Given what Gene wrote about the startup files, and that you are > using the stock ntpd, I would suggest just playing with the startup > order in rc3 (rc5?), rather than mess with rc.local. > I tried that for the overnight shutdown. It didn't work because there was still a problem with the wifi connection. > Not to sound completely ignorant, but is there a > management/configuration interface which can be used to set up the > wifi services? I have just been calling scripts from rc.local in > order to get wifi working. > There is - system-config-network, and it doesn't help at all. It appears that I either accept what network manager decrees - and that means dhcp, or do without. I'm fed up of struggling with this. Anne
