Monday, November 30, 2009

Re: [BLUG] uptime no reset at 1024

I stand corrected.

It might be interesting to see how 'uptime(1)' gets the information.

A man of times(2) shows the return value (a clock_t) was the time when
the system was booted for 2.4 series kernels, but that's no longer the
case for 2.6 kernels.

Cheers,
Steven Black

On Mon, Nov 30, 2009 at 05:12:03PM +0000, Mark Krenz wrote:
>
> Your Occam's Razor smack down has been canceled out by evidence.
>
> Linux kernels USED TO wrap around their uptime at 497 days. This was
> due to how the uptime was stored in the kernel. As a measument of
> jiffies. Jiffies used to be set to 100 per second, but can now be
> adjusted to even 1000 per second. This is what that 100Hz, 250Hz, 1000Hz
> setting is in the kernel config. Thus the time stored in the uptime
> used to be limited to 2^32 seconds / 100jiffies / 86400 sec/day = 497days
>
> I noticed once that the shell server at Kiva, which is still running
> on the 2.2 kernel, wrapped around its uptime at 497 days like this.
>
>
> Anyways, I had heard offhand comments that the number of days might
> wrap around at 1024 days, so I was curious if something might happen at
> 1024 days. It wasn't really based on the above, it was just based on
> heresay and anecdotal evidence.
>
> After all, I found that the load average itself wraps around at
> 1024.0 on 2.4 kernels at least. And yes, I did see a machine reach a 1
> minute load average of over 15000. I had to determine this by using some
> logs I had that showed that it was wrapping around. The machine in
> question wasn't really using that much CPU, it was load that was based
> on deadlocking samba processes that were trying to run 'df' on a machine
> with hung NFS mounts.
>
> Mark
>
> On Mon, Nov 30, 2009 at 04:43:58PM GMT, Steven Black [blacks@indiana.edu] said the following:
> > Let's think realisticly. (Or, perhaps, provide an Occam's Razor smack
> > down.)
> >
> > The uptime is a time, so it is likely stored in a time_t. This means it
> > would normally be subject to the same year 2038 Unix Epoch wrap provided
> > the system used 32-bit time_t values.
> >
> > However, it is stored as a relative time, so the that the beginning of
> > this particular epoch was when the machine was started up. This means it
> > wouldn't be expected to wrap until (2038 - 1970 =) 68 years from when
> > you started it up. And again, this is only if it is a 32-bit machine
> > with a 32-bit time_t.
> >
> > Cheers,
> > Steven Black
> >
> > On Mon, Nov 30, 2009 at 01:49:10PM +0000, Mark Krenz wrote:
> > >
> > > # w
> > > 08:48:11 up 1028 days, 0 min, 6 users, load average: 0.03, 0.19, 0.17
> > >
> > > I was wondering if the days would wrap around at 1024 days. I guess
> > > they don't.
> > >
> > >
> > > --
> > > Mark Krenz
> > > Bloomington Linux Users Group
> > > http://www.bloomingtonlinux.org/
> >
> > _______________________________________________
> > BLUG mailing list
> > BLUG@linuxfan.com
> > http://mailman.cs.indiana.edu/mailman/listinfo/blug
> >
>
> --
> Mark Krenz
> Bloomington Linux Users Group
> http://www.bloomingtonlinux.org/
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug

--
Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

No comments: