responses inline . . . "Carlos E. R." wrote:
El 02.09.29 a las 20:15, Michael D. Schleif escribió:
Date: Sun, 29 Sep 2002 20:15:17 -0500 From: Michael D. Schleif
I imagine we're saying the same thing.
cmos is set to utc.
I went into yast/yast2 and changed the configuration to match.
When I exited out of yast/yast2 the system clock is still set to utc. No matter what I changed in yast/yast2, *NO* change is exhibited in the system. Yet, my changes persist in yast/yast2 when I reenter yast/yast2.
Did you remember to close the sesion and login again? For a change in locale you need that. I think you might even need a reboot, if the hwclock is changed, but I'm not sure.
No, I didn't know that is required. However, I didn't change tz; rather, I changed the difference between hardware and system clocks.
What does work, as I stated in my original post, is the cli hwclock invocation.
Yes, the two (2) date commands work correctly, as you suggest.
You mean that "date" gives the correct local time. Then, what is wrong? Sorry, I don't understand.
Sure, the internal clock keeps the time in UTC, but programs will get the correct local time when they ask for it. That is the recomended way, but you may set everything to the local time (hw clock included), if you like.
Yes, I know this. What I do *not* know is the SuSE way to manage this.
What is the SuSE way to make this change persist?
<snip />
On other *NIX'es, there exist init files that make that hwclock invocation, so each time the system boots, cmos and system clocks are synced.
I cannot find any such init script on SuSE.
What am I missing?
It is there, I found it greping with mc on the appropiate dirs O:-)
I think the adjustment is in the /etc/localtime file, which is copied from somefile in the /usr/share/zoneinfo/ directory. The time is adjusted during init in /etc/init.d/boot:
# set and adjust the CMOS clock if test "$HWCLOCK_ACCESS" = "no" ; then echo -n Setting up the system clock # On s390 the hwclock is set outside Linux currently. The kernel # always assumes it to be set to UTC. So if it is set to local # time, we have to compensate for that. We might achieve this # using this special settimeofday(2) linux feature: # Under Linux there is some peculiar `warp clock' semantics # associated to the settimeofday system call if on the very # first call (after booting) that has a non-NULL tz argu- # ment, the tv argument is NULL and the tz_minuteswest field # is nonzero. In such a case it is assumed that the CMOS # clock is on local time, and that it has to be incremented # by this amount to get UTC system time. No doubt it is a # bad idea to use this feature. (settimeofday(2) man page) # But unless someone complains we simply will use date(1) to shift # the system time by the difference between UTC and local time, if # the system clock is set to local time. This will introduce a # minimal shift due to the delay between gettimeofday and # settimeofday, and it only works as long as $0 is executed # exactly once, at boot. if test "$GMT" = ""; then date $(date -u +'%m%d%H%M%Y') rc_status fi rc_status -v -r else echo -n Setting up the CMOS clock test -f /etc/adjtime || echo "0.0 0 0.0" > /etc/adjtime if test "$GMT" != "YAST_ASK" ; then /sbin/hwclock_wrapper --adjust $GMT rc_status /sbin/hwclock_wrapper --hctosys $GMT rc_status fi rc_status -v -r fi
And then, the script "halt" may copy it back from system to CMOS
if test "$HWCLOCK_ACCESS" != "no" ; then echo -n "Set Hardware Clock to the current System Time:" if test "$GMT" != "YAST_ASK" -a "$START_XNTPD" = "yes" -a -n "$XNTPD_INITIAL_NTPDATE" ; then # write back to hardware clock and calculate adjtime /sbin/hwclock_wrapper --systohc $GMT rc_status fi rc_status -v -r fi
Clearly, we are either working on entirely different systems, or my system is missing critical items: # grep -i hwclock `find /etc/init.d ! -type d` /etc/init.d/boot: HWCLOCK_ACCESS=no /etc/init.d/boot:if test "$HWCLOCK_ACCESS" != "no" ; then /etc/init.d/boot:CLOCKCMD=hwclock /etc/init.d/boot: *MTX\ Plus*) CLOCKCMD="hwclock --mtxplus --directisa" ;; /etc/init.d/boot: *PReP\ Dual\ MTX*) CLOCKCMD="hwclock --mtxplus --directisa" ;; In fact, hwclock on this system -- from which I grep'ed -- does not include the --mtxplus option ;< What is wrong with this system? What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . .