init process older then last boot

[Geoff Wild]

Not that this is too big of a deal - just thought this was interesting:

On a RP7410 Hard Partition, runing 11.23:

# date
Fri May 30 07:08:36 MDT 2008

# uptime
7:07am up 61 days, 16:55, 3 users, load average: 0.52, 0.63, 0.60


# ps -ef |grep init
root 1 0 0 Dec 31 ? 2:00 init
root 22 0 0 Dec 31 ? 2:09 pagetableinit_daemon

# last |grep reboot
reboot system boot Sat Mar 29 13:33 still logged in
reboot system boot Tue Feb 5 10:17 - 13:33 (53+02:16)
reboot system boot Thu Sep 13 08:53 - 10:17 (145+02:24)
reboot system boot Thu Sep 13 07:53 - 08:53 (00:59)

Isn't that strange?

Rgds...Geoff

[Steven Schweda · Accepted solution]

Knowing nothing, I'd assume that the system
time was off when the OS started up, and was
reset later, after those processes were up
and running. (Actual knowledge or
experimentation could probably test this
guess.)

[Patrick Wallek]

That is very strange. The only thing I can see is that somehow an incorrect time hash was stored when the system started.

Are there any other processes running from "Dec 31"?

[Geoff Wild]

# ps -ef |grep Dec
root 1 0 0 Dec 31 ? 2:00 init
root 8 0 0 Dec 31 ? 0:00 kmemdaemon
root 9 0 0 Dec 31 ? 0:03 ioconfigd
root 10 0 0 Dec 31 ? 2:12 nfsktcpd
root 11 0 0 Dec 31 ? 0:11 autofskd
root 12 0 0 Dec 31 ? 2:54 lvmkd
root 13 0 0 Dec 31 ? 2:57 lvmkd
root 14 0 0 Dec 31 ? 2:54 lvmkd
root 15 0 0 Dec 31 ? 2:58 lvmkd
root 16 0 0 Dec 31 ? 2:53 lvmkd
root 17 0 0 Dec 31 ? 2:58 lvmkd
root 18 0 0 Dec 31 ? 5:27 lvmschedd
root 19 0 0 Dec 31 ? 21:03 ksyncer_daemon
root 20 0 0 Dec 31 ? 0:18 lvmdevd
root 21 0 0 Dec 31 ? 0:00 lvmattachd
root 22 0 0 Dec 31 ? 2:09 pagetableinit_daemon


And we do run ntp - if it was out that much - then ntp wouldn't have synced...

No one set the clock prior to the last boot nor after.

Rgds...Geoff

[James R. Ferguson]

Hi Geoff:

Yes, interesting. I wonder if the "Dec 31" is really a zero time value. For example, in my EST5EDT timezone if I ask for the epoch time of zero my localtime appears to be "Dec 31":

# perl -le 'print scalar localtime(0)'
Wed Dec 31 19:00:00 1969

It would be interesting to look for the timestamps of other processes started by 'initd':

# who -p

# who -d

Regards!

...JRF...

[Geoff Wild]

Okay - I think I got it - we did a memory upgrade that day...

In the ntp log:

31 Mar 10:22:05 xntpd[19153]: synchronized to 192.168.111.49, stratum=3
31 Mar 10:22:05 xntpd[19153]: time error 2372.314892 is way too large (set clock manually)
31 Mar 11:09:19 xntpd[19906]: synchronized to 192.168.111.49, stratum=2
31 Mar 11:09:15 xntpd[19906]: time reset (step) -3.438099 s
31 Mar 11:09:15 xntpd[19906]: synchronisation lost
31 Mar 11:14:09 xntpd[19906]: synchronized to 10.8.60.47, stratum=2

And in the admin who did that change, in his .sh_history:

# grep "date 0331" /.sh_history_tchadmin
date 03311104


Strange - clock must have reset during the memory upgrade...

Rgds...Geoff

[Geoff Wild]

See above.

[Patrick Wallek]

JRF has stated much more eloquently exactly what I was thinking.

Are you up to date on init patches and firmware on this system?

[Steven Schweda]

> Strange - clock must have reset during the
> memory upgrade...

A dead clock battery might account for that.
I assume that you had the power (_really_)
off while the box was open. (Many things are
possible.)