gil@limbic.UUCP (Gil Kloepfer Jr.) (09/20/88)
Has anyone else experienced this phenomena? My system was only up for a day,
but ps reports:
UID PID PPID C STIME TTY TIME COMMAND
root 0 0255 Apr 20 ? 1408:55 swapper
root 1 0 3 Apr 20 ? 0:12 init
root 2 0 1 Apr 20 ? 0:00 pagedaemon
root 3 0 3 Apr 20 ? 3:49 windaemon
gil 535 1 3 07:01:25 w1 0:06 ksh
root 1209 1 3 22:44:08 ? 0:00 uugetty
gil 1218 535 3 22:47:00 w1 0:01 postnews
gil 1219 1218 9 22:47:33 w1 0:02 vi
root 109 1 3 23:01:53 w1 0:26 cron
gil 1221 1219 15 22:48:09 w1 0:00 sh
gil 1222 1221 75 22:48:10 w1 0:01 ps
that my system processes were started on April 20. Note that I did a
hardware reset when I booted the machine the last time. Could this be
taking the time from a software R/T clock which hasn't been set yet until
the hardware R/T clock is copied to the software one during some phase of
the boot process? I know that sometimes the STIME is correct, but I
really don't have the desire to keep rebooting the machine to find out when.
+------------------------------------+----------------------------------------+
| Gil Kloepfer, Jr. | Net-Address: |
| ICUS Software Systems | {boulder,talcott}!icus!limbic!gil |
| P.O. Box 1 | Voice-net: (516) 968-6860 |
| Islip Terrace, New York 11752 | Internet: gil@icus.islp.ny.us |
+------------------------------------+----------------------------------------+ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/21/88)
In article <369@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: >Has anyone else experienced this phenomena? > Could this be >taking the time from a software R/T clock which hasn't been set yet until >the hardware R/T clock is copied to the software one during some phase of >the boot process? When Unix boots, it uses the update time of the superblock of the root filesystem to set its clock. This is usually whatever time that disk was last written to (usually just before the system went down). On the Unix PC the hardware time-of-day clock is set by /etc/rc, so any processes created before that point will have incorrect STIMEs. The most annoying problem I have with this is that the boot time in /etc/utmp is wrong, causing the "uptime" to be off by however long your system was turned off. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/21/88)
In article <369@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: >Has anyone else experienced this phenomena? My system was only up for a day, >but ps reports: > > UID PID PPID C STIME TTY TIME COMMAND > root 0 0255 Apr 20 ? 1408:55 swapper ^^^^^^ I just realized that my previous posting didn't do much toward explaining this, so I'll take a guess... could the date have been set to Apr 20 just before you shut your system down prior to the most recent boot? -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com