Re: 2.4.x kernel uptime counter problem
Date: Thu Jan 19 2006 - 04:28:27 EST
On 1/19/06, Rumi Szabolcs <rumi_ml@xxxxxxx> wrote:
> I've got a Linux system running the 2.4.26 kernel which was about
> to pass the 500 day mark these days and now suddenly what I see is
> that the uptime counter has reset:
> $ uname -a && w && cat /proc/uptime && last -1 reboot
> Linux quasar 2.4.26 #3 SMP Tue Sep 7 09:22:08 CEST 2004 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz GenuineIntel GNU/Linux
> 09:38:08 up 1 day, 12:49, 5 users, load average: 0.00, 0.00, 0.00
> USER TTY LOGIN@ IDLE JCPU PCPU WHAT
> rumi pty/s0 08:53 0.00s 0.04s 0.02s screen -r
> rumi ttyp1 10Sep04 31:58 9:12 9:12 epic
> rumi ttyp3 Tue12 44:33m 0.01s 0.01s -/bin/bash
> rumi ttyp2 13Feb05 8days 0.11s 0.11s -/bin/bash
> rumi ttypc 11Dec05 0.00s 0.12s 0.11s -/bin/bash
> 132596.51 39801752.60
> reboot system boot 2.4.26 Tue Sep 7 18:47 (498+15:50)
> From the above it can be seen that the system is running continuously
> and wasn't rebooted 36 hours ago as the uptime counter would suggest.
> Is this a known bug?
It's not a bug - it is a feature. uptime rolls over after 497 days.
It computes the result of the "uptime" based on the internal "jiffies"
counter, which counts the time since boot, in units of 10
This is typecast as an "unsigned long" - on the Intel boxes, that's an
unsigned 32-bit number.
Well, it turns out that in a 32-bit number, you can store 497.1 days
before the number wraps.
You can use:
last -xf /var/run/utmp runlevel
to get true uptime in this instance.
"Person who say it cannot be done should not interrupt person doing it."
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/