On Mon, Jul 11, 2011 at 7:31 PM, Joe(theWordy)Philbrook <jtwdyp@ttlc.net> wrote:

It would appear that on Jul 11, Thomas Bächler did say:

...

This is no reason. Especially if you dual-boot, keeping the hardware clock in UTC is something to make your life so much easier.

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.

...

...

1) just what "Known" bugs that this could lead to are "UNFIXABLE"???

- Inconsistencies due to switches from/to DST. - Weird bugs (like in fsck) due to time changing during bootup.

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.

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). 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). HTH, Tom

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

On Mon, Jul 11, 2011 at 7:31 PM, Joe(theWordy)Philbrook <jtwdyp@ttlc.net> 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_th... 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@ttlc.net> | ? ?

Le mardi 12 juillet 2011 à 20:41 +0200, Tom Gundersen a écrit :

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

I just check my /var/log/messages.log to see if there date time changing all of the sudden, especially because I use HARDWARECLOCK="localtime" ( UTC+2 here) And I found something very strange The kernel boot in "local time": at least the log in /vaR/log/messages.log are in local time as soon there is some log about the kernel boot up Jul 15 10:26:35 soho kernel: [ 0.000000] Initializing cgroup subsys cpuset all the other are also in localtime BUT all line about rtkit-daemon are in UTC ! that's what I found strange even hours after the boot, rtkit-daemon line in mesageS.log still use UTC instead of local time ! how is this possible ? look at it Jul 15 13:15:34 soho kernel: [10164.898981] gnome-settings-[16527]: segfault at b5484160 ip b5484160 sp bf88261c error 4 in libdbus-1.so.3.5.7[b54b8000+47000] Jul 15 11:15:40 soho rtkit-daemon[1331]: Successfully made thread 29613 of process 29613 (/usr/bin/pulseaudio) owned by '120' high priority at nice level -11. Jul 15 11:15:41 soho rtkit-daemon[1331]: Successfully made thread 29614 of process 29613 (/usr/bin/pulseaudio) owned by '120' RT at priority 5. Jul 15 11:15:41 soho rtkit-daemon[1331]: Successfully made thread 29615 of process 29613 (/usr/bin/pulseaudio) owned by '120' RT at priority 5. Jul 15 13:15:41 soho gdm-simple-greeter[29620]: Gtk-WARNING: gtkwidget.c:6794: widget not within a GtkWindow Jul 15 13:15:41 soho gdm-simple-greeter[29620]: WARNING: Unable to read from file /etc/arch-release Jul 15 13:15:41 soho gdm-simple-greeter[29620]: Gtk-WARNING: gtk_widget_size_allocate(): attempt to allocate widget with width -47 and height -47 Jul 15 11:15:47 soho rtkit-daemon[1331]: Successfully made thread 29686 of process 29686 (/usr/bin/pulseaudio) owned I think I am gonna swtich to UTC for HARDWARECLOCK

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

On Jul 12, 2011, at 15:18, "Joe(theWordy)Philbrook" <jtwdyp@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@ttlc.net>>

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.

It would appear that on Jul 13, C Anthony Risinger did say:

On Jul 12, 2011 8:19 AM, "Joe(theWordy)Philbrook" <jtwdyp@ttlc.net> wrote:

<snip>

Duuuuude ... just set UTC and forget about it ... forever :-)

The wisdom of others frees time to build more wisdom of self.

Duuuude ... If my personality type was compatible with just doing things the way others have decided were best just because it's easier I'd never have fought my way out of Microsoft's grasp... When I first heard of Linux I didn't find it easier than winblows. (And except for the fact that I'm out of practice {and out of touch with changes in their propitiatory interface} I still wouldn't find it "EASIER") But what attracted me to it was the power of the bash shell (which I had become minimally exposed to via vt100 terminals connected to my former employers Unix machines) And the idea that if I could only figure out how, I could make my own durned decisions about how to set things up. A concept inspired by the fact that a guy I delivered stuff to at the factory had imposed his will on his Unix shell's command line prompt so that it read: Gone fishing: Well I didn't like his prompt. But I liked the idea of a user being able to decide such things for himself. And that, more than anything else made me decide I'd rather fight with *nix to get things the way I want than learn to live with what MS wanted to spoon feed me. Over the years I've made MANY non-standard adaptions to my Linux. Like for example among multi-boot (as in more than one Linux distro) users it seams the prevailing wisdom was to have one /home partition that gets mounted regardless of which Linux you boot. But I've seen that sometimes different Linux will have different versions of the same applications with incompatible .rcfile formats... So when I got ready to do something like that I created a user owned data partition that mounts (noauto,user) during my .bash_profile execution with symlinks in the various distro specific /home/jtwdyp directory trees... I NEVER let anything automount or automatically open an application on a removable filesystem upon insertion. But rather make it easy for "user" to mount/umout the usual ones at will. IE these lines in my fstab: /dev/disk/by-id/usb-USB_Flash_Disk_2008032800001952-0:0-part1 /Shuttle/gray auto user,noauto 0 0 /dev/disk/by-id/usb-TOSHIBA_TransMemory_5B8603000081-0:0-part1 /Shuttle/white auto user,noauto 0 0 /dev/disk/by-id/usb-USB_2.0_USB_Flash_Drive_0000000064DDE527-0:0-part1 /Shuttle/mini auto user,noauto 0 0 /dev/disk/by-id/usb-Generic_USB_SD_Reader_2004888-0:0-part1 /Shuttle/Camera-SD-1 auto user,noauto 0 0 make it easy with mc to select {for example} the dir: "/Shuttle/Camera-SD-1" type "mount <alt>+<Enter> <ENTER>" and use mc to access my latest images... This method works even if I didn't start the gui... In short {as if that were possible with me tehe} I have sufficient knowledge of "self" to know that while I may sometimes have problems with implementing my choices, & while I seek sufficient understanding of the wisdom of others to better evaluate my own choices, I myself will only ever change those choices when it feels right to me. And thus I'm resigned to the fact that MY pc will always be filled with a bunch of half understood kludges that at least temporarily let me run things my way even when the developers took a seriously different path... But the fact that I'm allowed to make my own choices, even if they are not advisable, makes me "love" Linux, and be at peace with my alleged place within it. Which is probably as blissfully "zen" as I'll ever get... <snicker> -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>