> I just upgraded to b129 today, and I've noticed that > my system clock is off by (exactly) 5 hours. Fine, > so I used the clock app to sync to an NTP server and > it pulled the correct time, updating the display and > everything. I clicked OK, the time in the > upper-right corner of the desktop changed to the > correct time, and immediately changed back to 5 hours > in the future. This can also be reproduced on the > command line: > > > pfexec ntpdate 0.pool.ntp.org; date; sleep 1; date > 15 Dec 12:52:45 ntpdate[4179]: step time server > 207.171.7.151 offset -17999.988088 sec > Tuesday, December 15, 2009 12:52:45 PM EST > Tuesday, December 15, 2009 5:52:46 PM EST > > Google suggests that this might be related to the > fact that I'm running in a dom0. It seems that Xen > exports the system clock in UTC, but *Solaris expects > the system clock to be the local time. But I've been > in a dom0 with various dev builds for at least three > months and never had a clock-related problem.
I'm not 100% sure I understand, but I _think_ that Windows in particular on the PC expects the battery powered hardware time-of-day clock to run in local time; therefore, all other PC OSs (that might have to multi-boot with Windows) have to make that same assumption. Solaris (and any Unix/Linux AFAIK) runs it's OS software clock as seconds since the start of 1 January 1970 GMT (UTC). I would _guess_ (never having played with xen/xvm) that the hardware TOD clock is simulated for the clients. Whether as a read-only of the actual hardware clock, or from the OS clock of dom0, I don't know... Add to that that the OS (client in this case) has to "know" what time zone the hardware clock is running in (to adjust it back to GMT to set the OS clock correctly) and things start to get interesting. (There's also the issue of DST, which the hardware clock ignores; I think a cron job runs to periodically reset the hardware clock from the OS clock after adjusting back to local time with DST rules taken into account.) Putting all those issues together, it wouldn't be hard for someone to either have overlooked something, or to have misconfigured either dom0 or a client so that strangenesses such as you describe could happen. It would take some real familiarity with both the TOD clock issues and xen/xvm as implemented in OpenSolaris to sort it all out, I suspect. > Interestingly, changing my time zone only pushes the > clock FORWARD. For example, changing from EST to > London time moved my clock ahead five hours (which I > would expect; also, it locked my screen, which is a > little weird but not unsurprising), but moving it > from London back to EST moved the clock ahead five > more hours on top of that. However, using ntpdate > after that (as above) restores the clock back to > where it was originally. > > Hmm, and on a hunch I just used the clock app to > "synchronize now," then manually reduced the number > it displayed by 5 hours, and now I have the correct > time. But if I run ntpdate after, it breaks the > clock again (and locks my screen, which is getting > really annoying). > > So I guess I discovered the workaround, but it would > be nice if I knew what was actually going on and why > it just now started happening. Locking your screen may be due to resetting the clock. X-window events have timestamps on them; if those get into unexpected order, strange things could happen. And if the time jumps forward, that could look like a period of inactivity and trigger a screen lock. I may have some of the details or terminology wrong, but I think most of what's happening is more or less covered by what I've mentioned, so that it's understandable what's happening, if not exactly what needs to be fixed. -- This message posted from opensolaris.org
