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

Re: [BLUG] uptime no reset at 1024

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

Re: [BLUG] uptime no reset at 1024

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

[BLUG] uptime no reset at 1024

# 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