bala@pebbles.Synopsys.COM (Bala Vasireddi) (10/25/90)
We are experiencing wierd problem on a Dn4500 running SR10.1. Problem 1: The date is wrong. So I halt the machine and execute 'ex calendar'. But, calendar thinks the date is already right (which in this case is 10/24/90). So I boot the machine and check the date. Viola, it is wrong again (this time it is: 10/25/90 00:48 or something like that). Also the Timezone is wrong. So as a last resort I set the date using the /bin/date command. This seemed to have worked, but this is not the correct way to set the date, right? Problem 2: A user 'test' logs into this machine. His/her home directory is mounted via nfs from a Sun. We are running nfs2.0. If the user types a pwd (or almost any command for that matter) in this login, this machine logs him out. Here is the output generated when I tried to su to test from 'root' login to debug this problem: # whoami root # su test % whoami status 90C0023 (UNIX/errno status) test % # # su test % cd % ls status 90C0023 (UNIX/errno status) % Reset tty pgrp from 192 to 189 (at this point I had to type <CR> to get the next prompt) % pwd //node_1d24d/sybil1/test status 90C0023 (UNIX/errno status) % # (Just to show that I am only having problems when I su to test, here is a transcript of this session whne I am logged in as root) # echo ~test /sybil1/test # cd ~test # pwd //node_1d24d/sybil1/test # ls -alg total 1840 drwxr-xr-x 10 test test 1056 Oct 25 1990 . drwxr-xr-x 9 root wheel 440 Oct 24 1990 .. -rwxr-xr-x 1 test test 96 Dec 13 1989 .X11 -rwxr-xr-x 1 test test 1058 Dec 13 1989 .Xdefaults -rwxr-xr-x 1 test test 1422 Oct 25 1990 .cshrc -rwxr-xr-x 1 test test 1812 Oct 25 1990 .cshrc.old -rwxr-xr-x 1 test test 12 Apr 24 1990 .forward -rw-r--r-- 1 test test 224 Oct 25 1990 .login -rwxr-xr-x 1 test test 1128 Aug 29 23:36 .login.old -rwxr-xr-x 1 test test 134 Dec 13 1989 .logout -rwxr-xr-x 1 test test 140 Dec 13 1989 .mailrc -rw-r--r-- 1 test test 18 Oct 18 17:35 .rhosts -rw-r--r-- 1 test test 165 Oct 9 22:44 .synopsys -rwxr-xr-x 1 test test 3398 Dec 13 1989 .uwmrc drwxr-xr-x 2 test test 176 Oct 17 16:48 doc drwxr-xr-x 3 test test 132 Oct 20 06:52 jott drwxr-xr-x 2 test test 396 Oct 17 16:48 man drwxr-xr-x 12 test test 2376 Oct 24 1990 qor drwxr-xr-x 2 test test 748 Aug 30 23:12 src drwxr-xr-x 5 test test 220 Oct 24 1990 test drwxr-xr-x 2 test test 264 Oct 24 1990 tmp drwxr-xr-x 7 test test 440 Oct 24 1990 unit -rw-r--r-- 1 test test 896319 Oct 25 1990 verilog.log -rwxr-xr-x 1 test test 1843 Oct 24 1990 x # Can anybody explain, what's going wrong here? Thanks. -- Bala Vasireddi, Phone: (415)962-5036 Synopsys, Inc. FAX: (415)965-8637 1098 Alta Ave DDN: bala@Synopsys.COM Mountain View, CA 94043 UUCP: ..!fernwood.mpk.ca.us!synopsys!bala
bala@pebbles.elan.com (Bala Vasireddi) (10/26/90)
We are experiencing wierd problem on a Dn4500 running SR10.1. Problem 1: The date is wrong. So I halt the machine and execute 'ex calendar'. But, calendar thinks the date is already right (which in this case is 10/24/90). So I boot the machine and check the date. Viola, it is wrong again (this time it is: 10/25/90 00:48 or something like that). Also the Timezone is wrong. So as a last resort I set the date using the /bin/date command. This seemed to have worked, but this is not the correct way to set the date, right? Problem 2: A user 'test' logs into this machine. His/her home directory is mounted via nfs from a Sun. We are running nfs2.0. If the user types a pwd (or almost any command for that matter) in this login, this machine logs him out. Here is the output generated when I tried to su to test from 'root' login to debug this problem: # whoami root # su test % whoami status 90C0023 (UNIX/errno status) test % # # su test % cd % ls status 90C0023 (UNIX/errno status) % Reset tty pgrp from 192 to 189 (at this point I had to type <CR> to get the next prompt) % pwd //node_1d24d/sybil1/test status 90C0023 (UNIX/errno status) % # (Just to show that I am only having problems when I su to test, here is a transcript of this session whne I am logged in as root) # echo ~test /sybil1/test # cd ~test # pwd //node_1d24d/sybil1/test # ls -alg total 1840 drwxr-xr-x 10 test test 1056 Oct 25 1990 . drwxr-xr-x 9 root wheel 440 Oct 24 1990 .. -rwxr-xr-x 1 test test 96 Dec 13 1989 .X11 -rwxr-xr-x 1 test test 1058 Dec 13 1989 .Xdefaults -rwxr-xr-x 1 test test 1422 Oct 25 1990 .cshrc -rwxr-xr-x 1 test test 1812 Oct 25 1990 .cshrc.old -rwxr-xr-x 1 test test 12 Apr 24 1990 .forward -rw-r--r-- 1 test test 224 Oct 25 1990 .login -rwxr-xr-x 1 test test 1128 Aug 29 23:36 .login.old -rwxr-xr-x 1 test test 134 Dec 13 1989 .logout -rwxr-xr-x 1 test test 140 Dec 13 1989 .mailrc -rw-r--r-- 1 test test 18 Oct 18 17:35 .rhosts -rw-r--r-- 1 test test 165 Oct 9 22:44 .synopsys -rwxr-xr-x 1 test test 3398 Dec 13 1989 .uwmrc drwxr-xr-x 2 test test 176 Oct 17 16:48 doc drwxr-xr-x 3 test test 132 Oct 20 06:52 jott drwxr-xr-x 2 test test 396 Oct 17 16:48 man drwxr-xr-x 12 test test 2376 Oct 24 1990 qor drwxr-xr-x 2 test test 748 Aug 30 23:12 src drwxr-xr-x 5 test test 220 Oct 24 1990 test drwxr-xr-x 2 test test 264 Oct 24 1990 tmp drwxr-xr-x 7 test test 440 Oct 24 1990 unit -rw-r--r-- 1 test test 896319 Oct 25 1990 verilog.log -rwxr-xr-x 1 test test 1843 Oct 24 1990 x # Can anybody explain, what's going wrong here? Thanks. -- Bala Vasireddi, Phone: (415)962-5036 Synopsys, Inc. FAX: (415)965-8637 1098 Alta Ave DDN: bala@Synopsys.COM Mountain View, CA 94043 UUCP: ..!fernwood.mpk.ca.us!synopsys!bala
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (10/26/90)
> <<forwarded message>> > We are experiencing wierd problem on a Dn4500 running SR10.1. > > Problem 1: The date is wrong. So I halt the machine and execute 'ex > calendar'. But, calendar thinks the date is already right (which in this > case is 10/24/90). So I boot the machine and check the date. Viola, it is > wrong again (this time it is: 10/25/90 00:48 or something like that). > > Also the Timezone is wrong. So as a last resort I set the date using the > /bin/date command. This seemed to have worked, but this is not the correct > way to set the date, right? The date you're seeing is probably right, if only you were in the right timezone! Since Apollos use the current time when they create an object on disk (they're not called UNIQUE identifiers as a joke), they don't want you changing the time just because daylight savings time starts (ends). Instead, they track everything in UTC (Greenwich Mean Time), and have a timezone offset. When you change the time zone, you change the effective LOCAL time that is displayed (although they still keep track of it in UTC). To change the time zone, use 'tz' (Example: "tz CST" will change us back from Central Daylight Time to Standard Time. We'll be doing it this Sunday, as a matter of fact. If for some reason you don't like using the time zone, you can use an offset instead, like "tz -10:00" to get Aleutian Standard Time (I think). YOu can use offsets with 30 minute increments as well (e.g. -4:30) if you have weird or funky timezones, and you can even NAME your time zone so that the machine calls it by your (up to 4 letter) name. What you can't get away with is changing the time to try and change the time-zone. (No help on problem #2 -- sorry) John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)
rees@pisa.ifs.umich.edu (Jim Rees) (10/26/90)
In article <9010260403.AA11351@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes:
(I think). YOu can use offsets with 30 minute increments as well (e.g. -4:30)
if you have weird or funky timezones, and you can even NAME your time zone so
that the machine calls it by your (up to 4 letter) name.
The 30-minute increment thing is (in my opinion) a bug in
cal_$decode_ascii_tzdif(), which is in kslib. The author of this routine
has a very small airplane and has never flown it as far away as Nepal or any
of the other countries that are not on 30-minute timezones. Now that we
have all those troops in Saudi, where time zones are on one minute
increments, it might be time to fix this.
You can get around this by calling the os routine cal_$write_timezone()
directly. The os stores time zones on disk in one minute increments.
By the way, it isn't immediately apparent, but you must reboot after
resetting the time zone.
Also, why do you have to be root to set the time, but anyone can set the
time zone?thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (10/27/90)
> <<forwarded message from Jim Rees>> > In article <9010260403.AA11351@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes: > (I think). YOu can use offsets with 30 minute increments as well (e.g. -4:30) > if you have weird or funky timezones, and you can even NAME your time zone so > that the machine calls it by your (up to 4 letter) name. > > The 30-minute increment thing is (in my opinion) a bug in > cal_$decode_ascii_tzdif(), which is in kslib. The author of this routine > has a very small airplane and has never flown it as far away as Nepal or any > of the other countries that are not on 30-minute timezones. Now that we > have all those troops in Saudi, where time zones are on one minute > increments, it might be time to fix this. Well, I can't be too hard on the author. I have never encountered a 30-minute offset, let alone a 1-minute one! (I guess that says I'm just a poor country hick from the Midwest. :-) > You can get around this by calling the os routine cal_$write_timezone() > directly. The os stores time zones on disk in one minute increments. > > By the way, it isn't immediately apparent, but you must reboot after > resetting the time zone. Huh??? We have never re-booted after setting time zone. In fact, I played around with it when I was writing my original reply, and had no problems. I believe you're mistaken on that count. > Also, why do you have to be root to set the time, but anyone can set the > time zone? Probably because setting the time has a direct effect on the O/S, while the time zone does not. Incidentally, you can fake the Apollos out and modify the date (through Aegis) even if you aren't root. Just run 'calendar' and say you have no disk. The adjusted time will still be recorded onto the disk when a shutdown occurs. (Note that this _does_ require a shutdown to take effect. Unlike the Unix 'date' (as root) command.) John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)
rees@pisa.ifs.umich.edu (Jim Rees) (10/30/90)
In article <4da18bc1.1bc5b@pisa.ifs.umich.edu>, rees@pisa.ifs.umich.edu (Jim Rees) writes:
By the way, it isn't immediately apparent, but you must reboot after
resetting the time zone.
I suppose I should have mentioned before you all rebooted that this is only
necessary if you are changing the actual zone you are in, not if you are
simply changing from daylight to standard time. The problem is that Unix
caches the time zone, and 'tz' doesn't update the cache.
Also, I've just been informed that the author of cal_$decode_ascii_tzdif
was last seen flying a twin Cessna 310.system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (10/31/90)
In article <9010261958.AA13955@pan.ssec.honeywell.com> thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes: >I have never encountered a 30-minute >offset, let alone a 1-minute one! (I guess that says I'm just a poor country >hick from the Midwest. :-) In Canada, we have Newfoundland which is 1/2 hour offset from Atlantic time. I know there is an Apollo at Memorial U. - I wonder what they use for a time zone setting. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775