Replying from phone, sorry fir brevity.
On Jul 12, 2011, at 15:18, "Joe(theWordy)Philbrook" <jtwdyp@xxxxxxxx> wrote:
>
> 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.
It should not make a big difference either way.
>> 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... ???
Correct.
> 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??
No, we adjust the time as soon as possible to minimize the problems (though we are not able to eliminate the gap when the time is wrong, so we simply don't know what might go wrong, the more init is optimized, the more likely we are to run across problems with this).
> 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"?
The fsck bugs are likely related to DST.
> 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.
Correct. And should still be that way.
> 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.
> 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?
No. The difference is just that ntpd will stay around adjusting for drift (though I guess drift will be the least of your problems with this setup).
> And if deamonized, would ntpd's syncing to the time server operation replace
> the process of adjusting for the RTC being in local time,
No. Timezone adjustment happens independently of ntpd (long before).
> 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??
Yup.
> 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.
Yes. It is independent.
> 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.
> 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"??
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).
Cheers,
Tom
