Am 13.08.2011 16:07, schrieb David Haller:
> Hallo,
>
> Rechne selber: was steht in /proc/uptime als erster Wert? Wenn der
> kleiner als der Zeitstempel in dmesg ist wird's natürlich negativ. Das
> liegt aber nicht an meinem Scriptfetzen, sondern an den Werten.
Ja der Wert in /proc/uptime ist kleiner. Rein formal rechnet das Skript
damit richtig, wenn man es einfach nur auf die vorliegenden Werte
bezieht. Trotzdem kann die Berechnung falsch sein, wenn mit falschen
Ausgangswerten gerechnet wird. Das scheint hier der Fall zu sein.
Das sollte auch keine Kritik an deinem Einzeiler sein, Ich hab ihn
einfach nur ausprobiert und ganz offensichtlich stimmte da was nicht.
Der Fehler würde auch mit den anderen Varianten auftreten.
Ein Überlauf war es jedenfalls nicht, Der Wert in /var/log/syslog und
dmesg weichen jedoch von /proc/uptime ab. Woher diese Abweichung kommt,
kann ich allerdings nicht nachvollziehen.
Auch auf einer anderen Maschine sehe ich Abweichungen:
~# uptime; tail -n 1 /var/log/syslog; dmesg | tail -n1; cat
/proc/uptime; date -d "$(dmesg|awk -F'[][ ]+'
'BEGIN{getline<"/proc/uptime";u=$1;} END{printf("%i\n",u-$2);}') seconds
ago"
20:36:40 up 48 days, 23:36, 1 user, load average: 0.14, 0.05, 0.01
Aug 13 20:36:40 srv12 kernel: [4231643.034000] ...
[4231643.034000] ...
4232178.03 33734620.97
Sat Aug 13 20:27:46 CEST 2011
Nach 48 Tagen Uptime hab ich hier eine Abweichung von ca. 9 min. Diesmal
liegt der Wert leicht in der Vergangenheit und fällt damit nicht gleich auf.
> Funktioniert also wie gefordert.
Kann man durchaus so sehen, gefordert war ja die Berechnung zwischen den
besagten 2 Werten.
Ich wollte damit nur sagen, daß diese Berechnung nicht uneingeschränkt
einsetzbar ist. Mag sein, daß es kurz nach dem Neustart noch hinreichend
genau ist, kann aber auch schnell zu Differenzen führen.
Gruß
Rico
Attachment:
smime.p7s
Description: S/MIME Kryptografische Unterschrift