On Sat, Jul 16, 2011 at 5:36 PM, Joe(theWordy)Philbrook <jtwdyp@ttlc.net> wrote:
myhost login: jtwd NTP: adjust RTC [0000012.0000001]yp Password:
Or some such thing. So unless the ntpd called from rc.local is NOT supposed to leave a message on tty1, I don't think that's a bug.
Ah, I see. That's as expected then.
hwclock has two purposes: adjusting for timezone offset (this is unchanged) and adjusting for drift (this is incompatible with ntpd/dualboot and is now in a separate daemon).
So then, If I understand you correctly, IF I'm going to use hwclock to fix RTC to localtime by including it in my daemons array, then I probably shouldn't put ntpd in the array as well or sooner or later the two daemons will be in conflict???
Hmm, no. What I meant is: The call to hwclock which adjusts for localtime, is independent of anything you put in your daemons array. It is only controlled by the HARDWARECLOCK variable in rc.conf. By putting hwclock or ntpd in DAEMONS (and you should not put both) you will adjust the time for drift, and this has nothing to do with the UTC v. localtime.
(and if so, is that "incompatibility" likely to manifest itself when hwclock is deamonized and ntpd is called once at startup {via rc.local}??)
The incompatibility is that hwclock will calculate (based on the values you use when you set/adjust the clock manually) how much your RTC drifts and will adjust for this. ntpd will update the RTC every 11 minutes to be in sync with the system time. If ntpd has already corrected the RTC, then hwclocks calculations will be wrong and it will overadjust. Again, these things are just about the drift, so you will probably not notice (it will only be a few seconds here and there). Though, I don't want to think about what happens to hwclock's drift calculations when you manually adjust for DST... Probably nothing good.
The way I see it, that if I'm going to keep my RTC set to local time, my choices are:
1) deamonize both (and let the daemons duke it out???)
No, never use both the ntpd and hwclock daemons.
2) deamonize hwclock and call ntpd in rc.local (may have similar if less persistent issue as above)
No. The hwclock daemon relies on being the only one adjusting the time (if you have multiple OS'es, only one of them can touch the time or you get in trouble), so don't call ntpd if you use the hwclock daemon.
3) deamonize ntpd and somehow call hwclock once at startup (would ensure that some attempt was made to adjust for "incorrect" startup system time due to local time being stored in the RTC, even if the internet isn't available, but may have the same risk of conflict as #2 AND may need to also somehow call hwclock at shut down to convert system time to localtime before the RTC is updated?)
The initscripts (have a look in /etc/rc.sysinit) already call hwclock once on boot to set the timezone, so if you set HARDWARECLOCK=localtime, and add ntpd to DAEMONS this is roughly what you get.
4) deamonize only ntpd (But without hwclock how do I update the RTC with local time on shutdown? OR does the term "ntpd/dualboot" refer to some configuration of ntpd where it will somehow store localtime in the RTC on shutdown without having to use hwclock???)
ntpd will write the correct time to RTC every 11 minutes, so no need to do anything with hwclock (except for the initial set that is done for you).
5) deamonize only hwclock and depend on my am habit of glancing at the localtime value stored in the RTC via the bios setup screen, before the days 1st OS boot {and manually fixing if incorrect} to solve DST issues and any {power off} RTC drift,etc... (of course this way my system time will never be more accurate than the clock on my office wall..)
This will probably mean that hwclock's drift calculations will get confused by your manual sets of DST. My advice to you is: Use ntpd and do not use the hwclock daemon. The only time using the hwclock daemon makes sense is if you know that nothing else touches the RTC (even other OS instances) and you are unable to use ntpd (and you are using your RTC in UTC). If you don't want/can't use ntpd, I suggest using nothing at all, and just adjusting the time manually when you notice it being off (basically treat your computer like an expensive wall clock). -t PS Or better still: set your clock to UTC and use ntpd to keep things accurate.