topic Re: init process older then last boot in Operating System - HP-UX

init process older then last boot

Geoff Wild — Fri, 30 May 2008 12:12:37 GMT

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

Re: init process older then last boot

Steven Schweda — Fri, 30 May 2008 12:25:04 GMT

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.)

Re: init process older then last boot

Patrick Wallek — Fri, 30 May 2008 12:25:40 GMT

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"?

Re: init process older then last boot

Geoff Wild — Fri, 30 May 2008 12:31:54 GMT

# 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

Re: init process older then last boot

James R. Ferguson — Fri, 30 May 2008 12:34:49 GMT

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...

Re: init process older then last boot

Geoff Wild — Fri, 30 May 2008 12:43:35 GMT

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

Re: init process older then last boot

Geoff Wild — Fri, 30 May 2008 12:44:46 GMT

See above.

Re: init process older then last boot

Patrick Wallek — Fri, 30 May 2008 12:46:35 GMT

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

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

Re: init process older then last boot

Steven Schweda — Fri, 30 May 2008 13:10:19 GMT

> 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.)