[arch-general] OK so HARDWARECLOCK="localtime" is "strongly discouraged" BUT???

[Joe(theWordy)Philbrook]

It would appear that on Jul 12, Tom Gundersen did say:

> On Jul 12, 2011, at 15:18, "Joe(theWordy)Philbrook" <jtwdyp at ttlc.net> wrote:

> > Whereas If I put "ntpd -qg &"
> > in rc.local there is sometimes enough time to type my username before the
> > NTP based time adjustment can be seen to occur..
> 
> Yes, ntpd is run in the background and might take some time to sync. It
> sounds like there might be a bug somewhere. You should not notice the ntpd set
> unless your clock is way off which should only happen due to DST (twice a
> year). Please check that your adjfile (/var/lib/hwclock/adjfile) is set to
> LOCAL, to match rc.conf.

Actually  I wouldn't notice the adjustment at all except that certain
system messages put things on the tty1 screen. So since I'm logging on to
the console instead of using some {Display Manager's} gui login screen,
there is {echoed?} to the screen a short oneline message about the
adjustment that includes several digits with a "." in the middle that I'm
assuming is a reference to how big the change was. At that point I don't
have gpm working so lets pretend it says "NTP: adjust RTC [0000012.0000001]"
n which case if I were starting to login as jtwdyp I might see:

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. 

> > And for that matter, perhaps more importantly, I always thought that
> > hwclock was the mechanism that did the adjustment to/from localtime at
> > startup and shutdown...
> 
> It is.
> 
> > Without hwclock, what process looks at the HARDWARECLOCK="localtime"
> > setting and performs the adjustment to and from "RTC localtime"??
> 
> 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???

(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 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???)

2) deamonize hwclock and call ntpd in rc.local
(may have similar if less persistent issue as above)

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?)

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???)

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..)

-- 
|   ~^~   ~^~
|   <*>   <*>       Joe (theWordy) Philbrook
|       ^                J(tWdy)P
|     \___/         <<jtwdyp at ttlc.net>>