It would appear that on Jul 11, Tom Gundersen did say:
> On Mon, Jul 11, 2011 at 7:31 PM, Joe(theWordy)Philbrook <jtwdyp@xxxxxxxx> wrote:
> > NOT dual-boot, Multi-boot, And I don't think in UTC <see above>
>
> The more OS'es you have, the better reason to keep RTC in UTC. You
> shouldn't need to _think_ about time at all... Anyway, if you want to
> do it, I will not try to persuade you otherwise.
Thank you! To me it's a freedom of choice issue. It may not be the wisest
choice I could have made. But I drew this particular line in the sand a
long time ago. And while I might even change my mind someday, I would do so
only for my own reasons and NOT because the prevailing wisdom says it would
be the wise thing to do...
> > OK I'll buy that I do NOT want fsck to phsck up my filesystem...
>
> The point is: The time in your system will from time to time be wrong,
> and this might lead to weird things happening. Usually with fsck.
Speaking of which, I have occasionally seen fsck be forced due to
{I think it said} "filesystems last access time in future" or some such
thing. Is that the most severe "weird" thing likely to happen with fsck?
> > Hence my willingness to put "ntpd -qg &" in rc.local and prevent system
> > time from "FIXING" my hardwareclock...
> > As much as I also don't like letting the internet set my system time.
> > (some things just shouldn't be totally automatic.) I mean if this
> > trend goes much further people will stop wanting to slice their own bread
> > anymore...<snicker>.
>
> If you insist on having RTC in LOCALTIME, then the best thing you can
> do is to set this value in rc.conf, and enable ntp (no need for
> rc.conf, just enable the daemon).
Actually, I got the rc.local (not rc.conf) method from an Arch wiki
https://wiki.archlinux.org/index.php/NTP
in the section labeled "Syncing the clock without running the daemon"
Again I recognize that the prevailing wisdom is that daemonizing the
process is better... But longstanding preferences die hard.
> This will work as well (or as badly) as it did before we added this
> warning, nothing really changed.
>
> For the record (for anyone else reading this): using LOCALTIME is
> never the right thing to do (though it will work "well enough" most of
> the time).
It would appear that on Jul 11, Buce did say:
> See
> http://mailman.archlinux.org/pipermail/arch-general/2011-April/019775.html and
> other posts in that thread.
Which left a trail of breadcrumbs to the wiki url:
https://wiki.archlinux.org/index.php/Systemd#Why_does_systemd_not_support_the_RTC_being_in_localtime.3F
Which in turn did say:
=> Recent kernels set the system time from the RTC directly on boot without
=> using 'hwclock', the kernel will always assume that the RTC is in UTC. This
=> means that if the RTC is in localtime, then the system time will first be
=> set up wrongly and then corrected shortly afterwards on every boot. This is
=> possibly the reason for certain weird bugs (time going backwards is rarely
=> a good thing).
Lets see if I understand... With the "recent" kernels, The system is
initialized using the RTC as a UTC reference. Then (at some point) it would
notice the HARDWARECLOCK="localtime" line in the rc.conf. In response to
which perform a math operation based on timezone data and then adjusts the
system time accordingly... ???
Am I right in thinking that any automatic fsck operation performed during
the boot {especially any such fscking of the root filesystem that is done
while it is still mounted "read only"} actually happens before the time gets
adjusted??
And that it is those fsck operations, rather than any manually commanded fsck
operations performed at other times on unmounted filesystems, that are most
likely to to be affected by those so called "certain weird bugs"?
Since I have for a long time kept my RTC set to localtime, did not have
NTP installed, and did have the time built into my tty login prompt.
(I boot to console then decide after login if & when to run startx
{granted 9 times out of 10 times it's my first user command}) And this
initial time reference on tty1 has matched my local time, I'm thinking the
time adjustment that compensates for the RTC having been in localtime must
happen before the 1st login prompt is issued. 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...
IF I ran NTP as a daemon (simply by adding "ntpd" to the "DAEMONS=()" line
in rc.conf?) instead of simply calling it from rc.local, would it sync the
system time to the server before the first tty prompt was generated?
And if deamonized, would ntpd's syncing to the time server operation replace
the process of adjusting for the RTC being in local time, or would the time
still be adjusted by whatever mechanism does it without NTP and then
afterwards, would NTP adjust the system time again to more accurately sync
it to the NTP server's time???
And whether run as a daemon or a rc.local process (as described in the NTP
wiki) does the system time still get corrected for the RTC in local time if
for some reason the NTP sever(s) can't be reached.
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... If as
http://www.archlinux.org/news/initscripts-update-1/
says:
=> The adjustment of the hwclock for drift is moved into a daemon that should
=> not be used in most scenarios as it can lead to subtle bugs (especially if
=> using dual-boot or ntp).
Without hwclock, what process looks at the HARDWARECLOCK="localtime"
setting and performs the adjustment to and from "RTC localtime"???
I thank you for your patience.
--
| ? ?
|
| -=- -=- I'm NOT clueless...
| <?> <?> But I just don't know.
| ^ Joe (theWordy) Philbrook
| --- J(tWdy)P
| <jtwdyp@xxxxxxxx>
| ? ?
