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 Cc: suse-linux-e List Subject: Re: [SLE] set system time ???

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.

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.

What is the SuSE way to make this change persist?

In my system, the change persist. I'll try right away. [...] Ok, I changed my local time to "Australia/Melbourne", and it is reflecting at once on all my consoles, even without relogin again. I'm using suse 7.3. cer@nimrodel:~> date Tue Oct 1 04:34:22 EST 2002 cer@nimrodel:~> date -u Mon Sep 30 18:36:15 UTC 2002 cer@nimrodel:~> Of course, the litle clock applet in gnome says it is half past eight, it will not change till I close the sesion. I think I recollect that kde showed the wrong time in my system. Is that what you mean?

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 -- Cheers, Carlos Robinson

Answer inline, text trimmed. El 02.10.01 a las 09:23, Michael D. Schleif escribió:

Date: Tue, 01 Oct 2002 09:23:04 -0500 From: Michael D. Schleif Cc: suse-linux-e List Subject: Re: [SLE] set system time ???

responses inline . . .

...

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.

From my tests, it seems not to be necesary; but I think it was necesary a year or so ago, last time I tinkered with this.

By the way, my version is 7.3 prof; I don't remember yours :-?

...

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.

It seems to be the file /etc/localtime that is changed as necesary, and the boot script.

Clearly, we are either working on entirely different systems, or my system is missing critical items:

Could be... what version do you have?

# 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 ;<

Mine neither. And it is not on my boot file.

What is wrong with this system?

What suse version do you have? And I suppose you have a PC, not something more strange, no? Those options could be for a different hardware. I could say more, perhaps, by looking at a bigger section of the boot file. But that only has effect when booting up, not when changing the time on a running system.

What do you think?

You could try to restore the boot file (it comes from aaa_base.rpm). Look for a file with a .rpmsave extension, like boot.rpmsave or boot.rpmnew or something similar. Read mails mailed to root when system was installed. The timezone information is copied to /etc/locatime from files like "/usr/share/zoneinfo/Europe/Madrid". Perhaps the one you chose does not exist or is bad. Those files come from timezone.rpm Another question. I think you said that the "date" command was working correctly, giving local time when asked, or utc with the -u switch, like: cer@nimrodel:~> date Wed Oct 2 01:35:42 CEST 2002 cer@nimrodel:~> date -u Tue Oct 1 23:35:45 UTC 2002 If that is so, what is exactly wrong in your system? I mean: which command gives the worng time? -- Cheers, Carlos Robinson

Ah, your version is a bit older than mine, I have suse 7.3. Thankyou for the update. I still have one question, however: which command is showing the wrong time? I think that you said that Yast corrected the time, but is was bad again when reboots, correct? To your question [a]: - It should read the CMOS clock and update system clock inside the script /etc/init.d/boot (miine does). Perhaps in your case the script got corrupted, replace with the original from aaa_base.rpm (check first). Maybe you could post here the relevant section. - The file holding the relation between local and utc time is "/etc/localtime". This file is copied (in your case) from "/usr/share/zoneinfo/CST6CDT", I think. I assume CDT time is "Global/CST6CDT" in yast? I have just changed my local time to yours, in yast2. Now date command shows: nimrodel:~ # date Wed Oct 2 13:08:53 CDT 2002 nimrodel:~ # date -u Wed Oct 2 18:08:57 UTC 2002 I noticed one thing: yast1 says it will be active after rebooting. With yast2 it is inmediate. - Try this: 1) Make sure the "date" command shows time as "CDT", as above (even if incorrect time, the CDT string must be present). If not, yast should correct it; perhaps try a different localtime (there are probably more than one with the same time difference). 2) Make sure you don't have a clock adjustement program or daemon like netdate, or ntpdate, or xntp client (START_XNTPD="no" and XNTPD_INITIAL_NTPDATE="" in /etc/rc.config). Stop the daemon if it exists, so that it doesn't interfere. Delete or rename /etc/adjtime (boot script in 7.3 recreates it, no problem). 3) Adjust to the correct localtime with "date -set" (not UTC). 4) Set the hwclock to the same time as the system, with "hwclock --systohc" (not UTC, it should know how to manage). 6) Check with "date" and "hwclock --show". They should be the same localtime: nimrodel:~ # date Wed Oct 2 13:26:14 CDT 2002 nimrodel:~ # hwclock --show Wed Oct 2 13:26:18 2002 -0.085997 seconds 7) Reboot to check. Keep fingers crossed 8-) -- Cheers, Carlos Robinson El 02.10.01 a las 20:41, Michael D. Schleif escribió:

Date: Tue, 01 Oct 2002 20:41:18 -0500 From: Michael D. Schleif Cc: suse-linux-e List Subject: Re: [SLE] set system time ???

<snip />

Thank you, for your continued participation.

Let's summarize:

[1] An associate installed sles 7.2 on a server, then asked me to remotely access it and correct those things that are not right.

[2] cmos and system clocks were both set to cdt -- I prefer cmos @utc and system @localtime.

[3] I had him reboot and set cmos clock to utc.

[4] I attempted to use yast/yast2 to correct this situation; which it did *NOT* do.

[5] I ran this from cli:

hwclock --hctosys --utc

[6] Other linux distros (e.g., debian) use this hwclock command in an init script to ensure that the two (2) clocks get synced at boottime.

[7] I cannot find any suse init script remotely close to this.

[8] I do not see how this suse system can maintain synchronization between cmos and hwclock.

This is my problem:

[a] What is the suse way to maintain this synchronization? What need I do to fix this the suse way?