when I run the 'date; command I get the following output: Mon Sep 11 15:12:45 EDT 2000; however when I create a file I get 15 Sep 11 19:13
for the file creation date. I do NOT have the hardware clock set to GMT.
I did not notice this with RedHat 6.1, and they both have the same timezone,
and are NOT set to use GMT.
What does 'zdump /etc/localtime say'?
[root@linux tim]# zdump /etc/localtime
/etc/localtime Wed Sep 13 07:04:50 2000 EDT
[root@linux tim]# touch test
[root@linux tim]# l test
-rw-r--r-- 1 1000 1001 15 Sep 13 11:05 test
NOTE: 'l' is just an alias of 'ls -l' The zdump gives the corest time;
however, when I create a file I still get the invalid time.
/sbin/clock shows the propper time (the time on the hardware clock), but
setting it to EST shouldn't change that should it.
I can't reproduce this... Does it still occur in 7.0?
I can not run 7.0 unless you nativley support the DPT SmartRAID V driver. I
have to wait for DPT to put out a Red Hat 7.0 driver. I think I found the
problems anyway. How do I reverse the "System uses UTC" option that you select
in the installation.
I start seeing this problem on our RH 6.2 system:
Fri Feb 23 11:43:14 PST 2001
$ touch /tmp/tmpfile
$ ls -l /tmp/tmpfile
-rw-r--r-- 1 root root 0 Feb 23 19:43 /tmp/tmpfile
I have the same problem on my 6.2 machine. I've tried everything, but the
timestamps are still wrong. It looks like 'ls' is not using the timezone and
reporting the time as UTC. This is an old bug, is anyone working on it?
# date >foo
# ls -l foo
-rw-r--r-- 1 root root 29 Mar 28 19:39 foo
# cat foo
Wed Mar 28 12:39:14 MST 2001
I noticed this same behavior on a 6.2 machine. I checked a 2nd 6.2 machine and
it behaved correctly. So I started looking deeper and found that we had a root
kit on the machine behaving incorrectly. The root kit replaced ls, find,
netstat, login, and many others. So if you experience this behavior, start
looking for a root kit. Just a word to the wise, don't trust your machine to
tell you what ports are open. If netstat and lsof are trojans, they won't help
you identifiy open ports (as was our case).
Assuming the root kit was responsible since I still can't reproduce this