Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!panix!not-for-mail From: JohnF Newsgroups: comp.os.linux.misc Subject: Re: time problem Date: Mon, 27 Oct 2014 04:35:20 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 218 Message-ID: References: NNTP-Posting-Host: panix3.panix.com X-Trace: reader1.panix.com 1414384520 26827 166.84.1.3 (27 Oct 2014 04:35:20 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Mon, 27 Oct 2014 04:35:20 +0000 (UTC) User-Agent: tin/2.0.0-20110823 ("Ardenistiel") (UNIX) (NetBSD/6.1.4 (i386)) Xref: csiph.com comp.os.linux.misc:12510 Rich wrote: > JohnF wrote: >> Rich wrote: >> > JohnF wrote: >> >> I've been having pretty much the same problem with slackware 14.1, >> >> and am not running windows in any way, shape, or form on this box. >> >> Every couple of days, some app seems to reset the hwclock to UTC. >> >> But date show blah-blah EDT 2014, and there's no... >> >> diff /etc/localtime /usr/share/zoneinfo/US/Eastern >> >> ...differences. I set the date, clock -w it, and it > >> > Which "it"? Output from 'date' or the HWclock contents? > >> Thanks for followup and info, Rich. "It" is from 'date'. Now that, >> thanks to your remarks, I'm researching it (the problem) better, I >> realize that 'date' isn't sufficient info. > >> >> remains edt for a few days, then suddenly I notice it's utc. >> > Which "it"? Output from 'date' or the HWclock contents? > >> As above, 'date'. > > That is quite strange. Provided you've got /etc/localtime set to your > correct TZ file (and your "diff" line indicates you do (although "cmp" > is the better choice than diff on binary files) then the output from > date should always show as local time. Now, the actual value "with a > EDT/EST suffix" may be incorrect, but that is different than date > outputting a string saying "UTC" (which is what your statement means > when I read it). Thanks again, Rich. cmp, as expected, also shows no differences. date has an EDT suffix, unless run as date --utc as shown below, or unless (for an experiment) I run timeconfig and change localtime to GMT, in which case suffixes are GMT. Right now, as I write this, timeconfig has localtime set to EDT, /etc/hardwareclock has UTC, box was booted that way, and outputs are... date Sun Oct 26 23:29:35 EDT 2014 date --utc Mon Oct 27 03:30:03 UTC 2014 hwclock -r Sun 26 Oct 2014 11:30:31 PM EDT -0.859741 seconds hwclock -r --utc Sun 26 Oct 2014 11:31:12 PM EDT -0.359708 seconds hwclock -r --localtime Mon 27 Oct 2014 03:31:45 AM EDT -0.312837 seconds Seems to be a hwclock glitch (I don't suppose it's relevant to my particular problem) that suffixes are always EDT, whereas date has edt time and EDT suffix, but date --utc has utc time and UTC suffix, which is what I'd expect. But hwclock -r --localtime shows correct utc numerical value, but followed by an EDT suffix. > The difference is: > o Date outputs a time string, suffixing EST/EDT, and the time string is > correct for current EST/EDT. Yes, this is what's happening right now, as illustrated above, and ... > o Date outputs a time string, suffixing EST/EDT, and the output string > is _incorrect_ for current EST/EDT, but would be a correct UTC time > string. ...Yes, this is what happens when date goes screwy: suffix remains EDT, but numerical value corresponds to utc (and day/date advance, too, if it's locally close to, but before, midnight). Unfortunately, I did not know enough to try date --utc with screwy clock, but will try that next time it happens. >> >> What could be causing that? > >> > Do you reboot between the time you set the HWclock, >> > and the instant you find UTC showing up somewhere? > >> Well, yes, but "find" is the operative word there. >> I'm not sure when it "actually happens" (during boot or >> otherwise) because I don't often notice the date. >> Mostly when I'm doing something like ls -alt|less >> to double-check what I've been working on, and >> notice it's screwy. > > To track things like this down, you may need to do one of several > things (and may need to do them all): > 1) always check the output from 'date' just before a shutdown, and > just after the next reboot and compare the values > 2) have some small clock visible on your desktop that displays > current time (including the EST/EDT) value that you can "keep an eye > on". > Item #2 above can be "simulated" by running this in an xterm/rxvt > (actually any terminal) window: > while true ; do date ; sleep 1 ; done > It will output one line per second, with the current values from the > date command. Change the "1" in "sleep 1" to other values for longer > delays, the "1" means wait one second. Thanks, Rich. Actually, I'm using fvwm2, with some ~/.fvwm/ modifications, and it's already displaying an xclock. What I have to do is actually look at it more regularly :) >> > If so, what is the contents of your /etc/hardwareclock file? >> That's localtime (and some #comments). > >> > Since you say you are not running windows, then quit trying to store >> > the hardware clock as localtime, have it set to UTC, and everything >> > will be fine. You'll still see localtime everywhere anyway. >> Okay, thanks. > >> > If /etc/hardwareclock already say UTC, leave it alone. If not, change >> > "localtime" to UTC in the file, and quit trying to have the HWclock be >> > local. >> Okay, done. >> Note: I ran timeconfig to make the change (as suggested by >> those #comments), and it says about localtime that >> "this is how most PCs are set up". But I nevertheless >> changed /etc/hardwareclock to UTC as you suggested. > > That "comment" is probably written with the assumption that "most PCs" > are, or will, also boot windows, and convincing windows to use UTC for > the hardware clock is quite a bit more trouble than having Linux > accomodate microsofts brain damage. Since you indicate you never run > windows on the machine, there's no point in accomodating microsoft > idiocy. Yeah, during install I just followed what seemed to be their recommendation. And never had any problems with previous slackware releases (though I jumped from 12.2 to 14.1, so can't comment on the intermediate ones). So never gave it much thought. >> > Then, set the system time if/when you need to adjust things (use the >> > date command, it also "sets/changes" the time). And then save the >> > result into the hardware clock with: >> > hwclock --utc --systohc >> Okay, done, but 'date' and 'hwclock -r' both still say the same >> numerical time, and both say EDT. I'm guessing I have to kill -HUP >> something, but I couldn't guess which pid from ps ax. I'll have to >> try a reboot (but that's tough to do in the middle of a reply:). > > Actually, modern hwclock's attempt to "remember" what was last used and > try to reuse that last value, from the Slackware 14.1 hwclock man page: > -u, --utc > --localtime > Indicates that the Hardware Clock is kept in Coordinated Universal > Time or local time, respectively. It is your choice whether to > keep your clock in UTC or local time, but nothing in the clock > tells which you've chosen. So this option is how you give that > information to hwclock. > If you specify the wrong one of these options (or specify neither > and take a wrong default), both setting and querying of the > Hardware Clock will be messed up. > If you specify neither --utc nor --localtime, the default is > whichever was specified the last time hwclock was used to set the > clock (i.e. hwclock was successfully run with the --set, > --systohc, or --adjust options), as recorded in the adjtime file. > If the adjtime file doesn't exist, the default is UTC time. > Older hwclocks did not try to "remember" and I just got into the habit > of always including --utc on any use I made of hwclock. Thanks for the additional info. I'd actually looked at man hwclock, but got that -r --localtime versus --utc backwards. I'd just expected --utc to display UTC, but it's apparently --localtime which does that. I didn't read it carefully enough the first time to realize my expectations were wrong. So my preceding remarks that hwclock -r was showing edt were based on incorrectly trying hwclock -r --utc. >> > Or, setup an ntp client to keep your clocks synced with the ntp >> > system on the internet, and just let the Slackware 14.1 rc.d >> > scripts save the system time to the hardware clock when you do >> > shutdown. > >> Didn't want to do that, but looked at those scripts for some clue >> about the process mentioned above. But all I could find was your >> preceding instructions hwclock --utc --systohc in rc.0 . > > Why not? It means your computer clock will always be set correctly. I don't always have the box on the internet. 90% of the time I'm just editing stuff, and the box is standalone (except for my lan with some NAS's for backup). Box almost always boots standalone. > If you don't want to try setting up the ntp deamons that come with > Slackware, the Chrony package > (http://slackbuilds.org/repository/14.1/network/chrony/) provides a > somewhat easier to setup deamon to sync to ntp time. You'll still have > to read the docs. to set it up properly however. Clock oscillator accuracy is more than enough for my purposes, which are really only that edited files be timestamped correctly. I want to ls -alt and see what I've been working on. If clock jumps ahead and I fix it when I notice it, then there's a four hour window (for EDT) where ls -alt is out of order. I can live with that if necessary, but was hoping there's an easy explanation/fix, especially since earlier slackware releases never had this problem (as far as I ever experienced). But situation now seems to be more complicated than I expected. Next time it happens (I wish I knew how to reproduce it at will), I'll be better able to document the machine state, which will maybe reveal the cause. >> > Just always give the 'hwclock' command the --utc flag and it will >> > translate the time from the hwclock into your local time for you when >> > you want to view/reset the hwclock. > >> Okay, as above, doesn't seem to be doing exactly that now, but I'll >> try a reboot and see if some process or other initializes itself with >> the new /etc/hardwareclock contents. > > Likely because of its "memory" effect from the man page. It tries to > be "helpful" and translate what is in the hardware into a value that > will make sense to you viewing it (i.e., into your local time if it > "remembers" you set the hwclock to UTC. If you want to read the actual > hwclock value without any time translation, just give hwclock the > --localtime option when you _read_ the clock and you'll see the actual > contents of the clock. > I.e., you can interpret --utc as "translate hwclock time to/from my > actual local time value when I set/read the clock" and --localtime as > "show me the raw contents of the clock, with no time translations". > Because in effect that is exactly what those two options do under the > hood. Yeah, as above, I'd misread/misunderstood the manpage, thinking --localtime would do the translation (still seems to me like that would be the natural interpretation, but I'm not complaining:). Thanks again, Rich, -- John Forkosh ( mailto: j@f.com where j=john and f=forkosh )