Newsgroup: it.comp.os.linux.sys
Titolo: uptime

Ultimamente ho buttato l'occhio su una cosa un po' curiosa: l'uptime
viene letto sotto /proc/uptime; e fin qui nulla di particolare.
L'anomalia viene facendo il cat del file in oggetto:
francesco@PrtKmTcx:~$ cat /proc/uptime
19201.56 33726.69
Se ho ben capito i due numeri indicano i tempi di uptime e di idle in
secondi ma non dovrebbe essere Tidle < Tup ?
Almeno così mi aspetterei. Mi viene il dubbio che Tidle sia dipendente
dal numero di cpu (o core) presenti sul sistema mentre Tup sia
linearmente funzione del tempo.
Altro dubbio: questi due valori hanno un limite massimo dopo il quale
vengono riazzerati o sono potenzialmente infiniti?

 vengono riazzerati o sono potenzialmente infiniti?
È un unsigned int, quindi dipende dal sistema. Su 32bit 4 miliardi e rotti 
di secondi, su 64bit molti di più :)
-- 
Vide

 di secondi, su 64bit molti di piï¿œ :)
  Se ho ben interpretato sono *due* unsigned int e potrebbe capiare che uno 
dei due si resetti prima (farï¿œ i conti su quanti sono i 4 miliardi di 
secondi)
-- 
Non pretendo che comprendiate il significato di quello che ho scritto senza 
averlo riletto un certo numero di volte. Personalmente, vi riterrei degli 
stupidi se lo faceste. Io l'ho letto sei volte ed ancora non l'ho capito.

 secondi)
Con 32bit son più di 135 anni. Non credo nessun hardware di questo calibro 
regga tanto in vita, senza tra l'altro mai spegnersi :)
-- 
Vide

 regga tanto in vita, senza tra l'altro mai spegnersi :)
  Infatti mi ero fatto i dovuti calcoli ed erano 136 anni e rotti. Comunque 
in base alle informazioni dette prima ci sarebbe la probabilitï¿œ che si 
resetti prima il Tidle (almeno in ambito SMP); il dubbio perï¿œ mi ï¿œ nato 
dalla situazione inversa (per ovvi motivi ho modificato il nome host):
[root@vvv tmp]# cat /proc/uptime
10657.74 84756976.45 
  La macchina ha segnalato un reboot (che non c'ï¿œ stato) e la situazione 
lato uptime era quella che vedi; ora escludo il reset del valore (dato che 
per ovvi motivi la macchina non sta su da 136 anni :) ) escludo l'alto 
numero di cpu ... e comincia a mancarmi qualcosa.
  Qui magari torna utile sapere che il kernel ï¿œ 2.4 (si tratta di una RH 3). 
Magari hai qualche link o riferimento per approfondire l'argomento? Potrebbe 
esser cambiato il modo in cui il kernel gestiva tali valori durante qualche 
revisione; poi in ogni caso ï¿œ sempre una lettura costruttiva.



uhm ... ma non dpovrebbe essere l'equivalente che passa dal 1970 al 
2039, ovvero 69 anni?
Non è la stessa cosa?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 2039, ovvero 69 anni?
  Resta comunque un tempo ragionevolmete elevato, ovviamente non guardando 
al futuro.
  P.S.: vado di OT ma fin'ora l'uptime piï¿œ alto che ho visto stava 
raggiungendo i 1500 gg ma non era una macchina linux.


 Non è la stessa cosa?
Quello è un signed int (la metà di ~136 anni). Può darsi che sia un signed 
int l'uptime, non ho spulciato i sorgenti del kernel
-- 
Vide


tempo fa aprii una discussione su questo:
08/01/2010
[FUN & STATS] massimo uptime

 raggiungendo i 1500 gg ma non era una macchina linux.
Cos'era? Windows 2003 server :) ?
-- 
g4b0, linux user n. 369000
http://brosulo.net

 Cos'era? Windows 2003 server :) ?
Prima dello sviluppo di Linux il mio "desktop" era una AlphaStation 200 
4/100 della Digital con sistema operativo DEC-Unix. E' stata accesa nel 
1995 ed e' stata spenta nel 2003. In questo periodo ho fatto il reboot 2 
volte per cambio hardware. Nel 2003 l'abbiamo dismessa perche' a causa 
del blackout nazionale (era una domenica di fine settembre) si e' spenta 
e si e' scassato l'alimentatore.  Non l'ho mai controllato, ma credo che 
l'uptime fosse su quella cifra (~1500 giorni).
Mauro

 Cos'era? Windows 2003 server :) ?
 Solaris 8, l'abbiamo rebootata per procedere ad un patching (poi rimandato 
per altre cause)
