Uptime på 2.4.x kernel

[Wraith]

Noen her som vet hvordan man får fjernet bug'en som gjør at uptime resettes ved 497 dager? dette bør helst kunne gjøres uten å reboote..

jeg har desverre bare funnet info om hvordan man gjør det som involverer reboot .. og det kan man jo ikke ha noe av

[Gronz]

Kan du kjøre "uptime --version"?

 

Edit: kjører du uptime fra en annen maskin via ssh eller lignende?

Endret 5. desember 2004 av Gimper

[Bøb]

Gjelder dette alle 2.4 kjerner? Kommer aldri opp til ~500 dager uten UPS på server'n, men det er jo lov å håpe

 

Btw; min Slackware 10 box med 2.4.26 box sier;

 

bo@slappserv:~$ uptime -V       
procps version 3.2.1

[Ueland]

32`bits mattematikk:

 

en 32 bits prosessor kan repetere tall fra 0 til 4294967295

 

4294967295 / 1000 = 4294967,295 (1000 ms i et skund)

4294967,295 / 3600= 1193,046470833333333333333333333 (3600 sk i en time)

1193,0464708333333333333333333333/ 24 = ~49,7

49,7 * 10 = 497 dager.

 

Forklart på engelsk her:

http://revjim.net/comments/9636/

32 vs 64 bit:

http://www.build-your-own-computer-tips.co...processors.html

 

Just my 2 cents

[Gronz]

32`bits mattematikk:

 

en 32 bits prosessor kan repetere tall fra 0 til 4294967295

 

4294967295 / 1000 = 4294967,295 (1000 ms i et skund)

4294967,295 / 3600= 1193,046470833333333333333333333 (3600 sk i en time)

1193,0464708333333333333333333333/ 24 = ~49,7

49,7 * 10 = 497 dager.

 

Just my 2 cents

Har nå sett mange som har hatt uptime på 6-700, så har en mistanke om at den grensen er der hvis du kjører uptime via ssh e.l.

[Ueland]

Mulig at dette "bugget" og kan ha blitt ordnet i en annen kernel / distro vel å merke...

[Bøb]

Dette er vel i så fall i kjernenivå, så ssh bør vel ha lite å gjøre med det å gjøre. Eller?

[Gronz]

Dette er vel i så fall i kjernenivå, så ssh bør vel ha lite å gjøre med det å gjøre. Eller?

Fant dette: http://archive.pilgerer.org/mharc/html/fre...6/msg00395.html , men det er om noe som heter Netcraft (hva nå det enn er), så er ikke sikker på om det samme gjelder for ssh.

[Bøb]

Det er vel kanskje via den egne uptime protokollen (ta en titt i inetd, skal stå noe om den der)? SSH er jo bare et lag mellom to maskiner, skal ikke ha noe å si på hva maskinen tror for noe.

[gspr]

32`bits mattematikk:

 

en 32 bits prosessor kan repetere tall fra 0 til 4294967295

 

4294967295 / 1000 = 4294967,295 (1000 ms i et skund)

4294967,295 / 3600= 1193,046470833333333333333333333 (3600 sk i en time)

1193,0464708333333333333333333333/ 24 = ~49,7

49,7 * 10 = 497 dager.

 

Forklart på engelsk her:

http://revjim.net/comments/9636/

32 vs 64 bit:

http://www.build-your-own-computer-tips.co...processors.html

 

Just my 2 cents

Hvorfor den magiske multiplikasjonen med 10? Det ser ikke det du linker til ut til å forklare heller.

[Ueland]

For å henvise til en annen forklaring og:

http://e-zine.nluug.nl/hold.html?cid=158

 

this counter is incremented every 0.01 second. The maximum value is 4,294,967,296 which translates to 42,949,673 seconds. To which my original calculated value compares well.

42,949,673 / 3600 = 11930,381388888888888888888888889

11930,381388888888888888888888889 / 24 = 497,0992245

 

The Linux kernel switched to a higher internal timer rate at kernel version 2.5.26. Linux 2.4 used a rate of 100Hz. Linux 2.6 uses a timer at 1000Hz. (An explanation of the HZ setting in Linux.)

 

The above applies to Linux on 32-bit Intel-compatible systems (which is the most common case). Linux on other platforms uses different timer rates: the Alpha and Intel ia-64 ports already used 1000Hz, while the ports for sparc, m68k and other less common processors continue to use 100Hz.

 

The Linux TCP code only uses the low 32 bits of the timer. Due to the faster rate of the timer, the value wraps around every 49.7 days (whereas it used to wrap after 497 days). Because there are large numbers of Linux systems which have a higher uptime than this, it is no longer possible to report accurate uptimes for these systems.

 

Er mange måter å se det på men de samme tallene kommer tilbake hele tiden.

[gspr]

Ah, den er grei. Takker.

[Wraith]

Hmm, desverre får jeg vel ikke til å bytte fra P2 til A64 cpu uten å reboote, så da får jeg vel overleve uten så mye uptime

 

takk for masse svar. de URL'ene var vel de jeg hadde kommet over før og, men var jo lov å håpe at det fantes noen her som kunne frelse meg

 

22:56:41 up 11 days,  6:16,  1 user,  load average: 0.00, 0.00, 0.00

--[ BitchX-Client-Statistics ]------------------------------------------

| Client Version: BitchX-1.0c19 20020325

| Client Running Since Fri May 28 12:39:06 2004

| Client Uptime: 191d 12h 17m 37s

det der ser lissom litt galt ut ikke sant? fra samme maskina, kjørt samtidig

[tivolieselet]

bare for å ta med noe på www.netcraft.com

 

"Why do some Operating Systems never show uptimes above 497 days ?

 

The method that Netcraft uses to determine the uptime of a server is bounded by an upper limit of 497 days for some Operating Systems (see above). It is therefore not possible to see uptimes for these systems that go beyond this upper limit. Although we could in theory attempt to compute the true uptime for OS's with this upper limit by monitoring for restarts at the expected time, we prefer not to do this as it can be inaccurate and error prone.

 

Why do you not report uptimes for Linux 2.6 or Linux alpha/ia64 ?

 

The Linux kernel switched to a higher internal timer rate at kernel version 2.5.26. Linux 2.4 used a rate of 100Hz. Linux 2.6 uses a timer at 1000Hz. (An explanation of the HZ setting in Linux.)

 

The above applies to Linux on 32-bit Intel-compatible systems (which is the most common case). Linux on other platforms uses different timer rates: the Alpha and Intel ia-64 ports already used 1000Hz, while the ports for sparc, m68k and other less common processors continue to use 100Hz.

 

The Linux TCP code only uses the low 32 bits of the timer. Due to the faster rate of the timer, the value wraps around every 49.7 days (whereas it used to wrap after 497 days). Because there are large numbers of Linux systems which have a higher uptime than this, it is no longer possible to report accurate uptimes for these systems."

 

 

men dersom du har over 470 dager så har du helt sikkert en del sikkerhets hull i på boxen og det er ikke bra.

[objorkum]

Kvifor har ein sikkerheitshol då? Må ikkje reboote på sikkerheits-oppdateringar, berre snakk om å f.eks restarte nokon tenester...

[Langbein]

Kan være noen exploits i kjerna da, men de krever selvsagt at man allerede har shell eller evt. kommet seg inn via en annen remote exploit i en daemon som tillater arbitary code execution.

[kyrsjo]

Mulig jeg tar feil med:

- "uptime" komandoen fortsetter å telle lenge

- den uptimen som blir rapportert "utenfra" (f.eks. av nmap) kalkuleres ut i fra et-eller-annet i TCP. Denne nullstilles.

 

Har jeg rett, eller tar jeg feil?