* Dominik Bay wrote on Fri, Dec 09, 2005 at 09:59 +0100:

Zombie Pseudoterminal und ueberlaufender Counter, wuerde ich mal sagen ;-)

[...]

9:35am up 494 days, 11:50, 1 user, load average: 0.00, 0.00, 0.00 [Overflow nach]

...

...

497 Tagen

Dann läuft Deine Uptime also Montag oder Dienstag über? Kannst Du dann hier mal ne Mail schreiben? Und der Überlauf passiert in /proc/uptime, sprich, der kernel macht es definitiv falsch? Man glaubt's ja kaum und hofft auf ein Bug in der uptime Zeit-Konvertierung... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

* Thomas Hertweck wrote on Sun, Dec 11, 2005 at 11:27 +0000: [...]

...

Und der Überlauf passiert in /proc/uptime, sprich, der kernel macht es definitiv falsch? Man glaubt's ja kaum und hofft auf ein Bug in der uptime Zeit-Konvertierung...

Was heisst der Kernel macht es falsch? Variablen haben einen gewissen Wertebereich, und wenn dieser nicht mehr ausreicht, kommt es zu einem Overflow - Du kannst natuerlich entsprechende Massnahmen ergreifen, um das zu erkennen und entsprechend zu handeln, aber nur mit gewissem Overhead. Man haette natuerlich statt eines "unsigned long int" den Counter als "unsigned long long int" definieren koennen, aber das gibt es IIRC erst seit C99...

Linux 2.4 gibt es noch nichtmal so lange, und neben long long gibt es sicherlich noch weitere Möglichkeiten, eine uptime korrekt auszurechnen. Man könnte sich z.B. den Bootzeitstempel speichern, läuft dann ein selbst bei Sekunden since epoch erst bissel später über, aber dann darf man seine Uhr nicht mehr stellen - obwohl der Kernel das natürlich "mitbekommt" (sprich: macht) und es daher korrigieren könnte. Obwohl uptime vermutlich eh nicht mehr funktioniert, wenn man die Zählfrequenz ändert (da war doch was mit "desktop Parameter"?). Man könnte auch den Überlauf schon nach 365 Tagen forcieren und die Überläufe mitzählen. Die nennt man dann "kernel-Jahre" oder so, ist deutlich genauer als ein einfacher Overflow. Falls man überhaupt einen 10ms genaue uptime braucht (bei einem Jahr Laufzeit :))... Na ja, ist ja auch egal :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

(OT) * Thomas Hertweck wrote on Wed, Dec 14, 2005 at 21:34 +0000:

Steffen Dettmer wrote:

...

[...] Obwohl uptime vermutlich eh nicht mehr funktioniert, wenn man die Zählfrequenz ändert (da war doch was mit "desktop Parameter"?).

Natuerlich funktioniert die Uptime - Du musst ja nur wissen, durch welche Zahl (HZ) Du Deinen Counter teilen musst. Wenn Du Deinen Counter 100 mal pro Sekunde erhoehst, musst Du den Counter eben durch 100 Teilen, um eine Zeit in Sekunden herauszubekommen. Wenn Du den Counter 1000 mal pro Sekunde erhoehst, musst Du eben durch 1000 teilen, usw.

Dann muss man sich aber merken, dass 0-1.000.000 ein 100Hz war, 1.000.001-2.456.789 bei 1000 weil der "Mplayer" lief, ab 2.456.790 war er wieder aus bis... ach, da war die Tabelle voll :-)

Wie ich schon schrieb, gibt es sicherlich Moeglichkeiten, auch ueber die z.B. 479 Tage hinaus eine Uptime korrekt anzuzeigen. Aber das ist verbunden mit gewissem Overhead, da Du ja stets ueberpruefen musst, ob Du langsam die Grenze des Moeglichen erreichst oder nicht.

wieso, wenn beim inc eax (oder was auch immer da genau gemacht wird) ein Überlauft passiert (da reicht ja schon ein Zeroflag), erhöht man halt noch einen Wert. Oder meinst Du die eine Assemblerinstruktion mit Overhead? Könnte man sicherlich mehr als ausgleichen, wenn man die Frequenz von 1000 auf 999 senkt :)

Und zu welchem Zweck das alles? Den Kernel interessiert die Uptime nicht, er braucht lediglich einen moeglichst genauen Timer Interrupt. Wozu also Zeit und Resourcen fuer ein unnoetiges "Feature" verschwenden...

Ja, den Kernel interessiert auch nicht, ob X läuft, also kann man den Computer auch auslassen... (?!) Ach so: MICH interessiert es :)

Leider wird die Uptime oft ueberbewertet. Es gibt so vermeindliche Linux-Freaks (oft zu finden im Heise-Forum), die sind furchtbar stolz auf ihre Uptime von >400 Tagen. Fuer mich waere so etwas kein Grund stolz zu sein, denn es besagt lediglich, dass sich jemand vermutlich mehr als ein Jahr lang nicht um Kernel-Security Fixes gekuemmert hat.

Ja, Linux muss booten, um einen Kernel zu wechseln, obwohl es da wohl mal so ein Projekt gab, glaube ich... Kann Hurd sowas eigentlich?

Wenn ein derartiges System oeffentlich ist, braeuchte ich lediglich im Kernel Bugtracker zu schauen, welche Exploits es evtl. innerhalb des letzten Jahres gab und schon stuenden mir unter Umstaenden leichte Moeglichkeiten offen, ein System zu hacken... Merci beaucoup!

Was meinst Du mit "öffentlich"? Das es ein passwortlosen Telnet-Zugang gibt? :-) Tja, also "leichte Möglichkeiten" ja überhaupt nur, falls Du denn eine Verbindung hinbekommst... Als ich früher Admin war, kam man nicht und überhaupt nicht an "interessante" Maschinen (und bei allen anderen war die uptime eh egal :)) (und heute haben Firmennetze eh fast alles hinter NAT, weil ja angeblich IPs knapp sind). (Aber schon klar, dass man sich immer irgendwie "durchbuddeln" kann). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

* Thomas Hertweck wrote on Sat, Dec 17, 2005 at 12:12 +0000:

Steffen Dettmer wrote:

...

[...] Dann muss man sich aber merken, dass 0-1.000.000 ein 100Hz war, 1.000.001-2.456.789 bei 1000 weil der "Mplayer" lief, ab 2.456.790 war er wieder aus bis... ach, da war die Tabelle voll :-)

Das ist Unsinn. Der Parameter wird beim Booten gesetzt und gilt damit solange Dein Linux-Kernel laeuft.

Ich fing ja an mit:

...

...

...

"Obwohl uptime vermutlich eh nicht mehr funktioniert, wenn man die Zählfrequenz ändert"

Schön, dass wir uns einig sind, dass es kein Problem ist, wenn man die Frequenz nicht ändert, sondern nur einmalig einstellt oder einkompiliert. :-)

Er ist nicht von einer Anwendung abhaengig und wird im laufenden Betrieb nicht geaendert.

Hast Du einen Link da, der den Kernel-boot-parameter dokumentiert? Du schriebst ja, der sei SuSE-spezifisch; google konnte mir nicht helfen. http://kerneltrap.org/node/464 sieht ja auf den ersten Blick nicht so "konfigurierbar" aus, sondern eher nach "einkompiliert". Hast Du da was zur Hand? Danke! google fand jemand, dessen "uptime" den Überlauf irgendwie korrekt handhabte. Vielleicht ist da doch ein Schutz implementiert?

...

[...] wieso, wenn beim inc eax (oder was auch immer da genau gemacht wird) ein Überlauft passiert (da reicht ja schon ein Zeroflag), erhöht man halt noch einen Wert.

Der Gag an einem Overflow ist ja gerade der, dass es nicht auffaellt und *keinen* Error produziert bzw. triggert:

(kommt darauf an, welche Programmiersprache man gerade zufällig verwendet, aber mir ist schon klar, dass Linux C ist :)) Ich war wohl zu knapp mit meiner Aussage, sorry. Ich versuche es nochmal ausführlicher. [... Overflow Beispiel C++ Programm ...] "dass es nicht auffaellt" - Disziplin muss vom Programmierer kommen, C erzwingt da nichts, ok. Kann man aber ganz einfach machen, hier zwei Beispiele (basierend auf Deinem, nur in C): #include #include int main(void) { short int i1 = 20000; printf(" (int) 20000 + 20000 == %d\n", (int) (i1+i1)); #if defined(SO_NICHT) printf("(short int) 20000 + 20000 == %d\n", (short int) (i1+i1)); #endif /* with Overflow check */ if (SHRT_MAX - i1 < i1) { printf("will overflow SHRT_MAX (%d - %d == %d > %d)\n", SHRT_MAX, i1, SHRT_MAX - i1, i1); } else { printf("OK, fits into SHRT_MAX (%d - %d == %d > %d)\n", SHRT_MAX, i1, SHRT_MAX - i1, i1); printf("(short int) 20000 + 20000 == %d\n", (short int) (i1+i1)); } /* alternative Overflow check */ if ((short int)(i1 + i1) < i1) { printf("will overflow SHRT_MAX (%d + %d == %d < %d)\n", i1, i1, (short int)(i1 + i1), i1); } else { printf("OK, fits into SHRT_MAX (%d + %d == %d < %d)\n", i1, i1, (short int)(i1 + i1), i1); printf("(short int) 20000 + 20000 == %d\n", (short int) (i1+i1)); } return 0; } produziert (int) 20000 + 20000 == 40000 will overflow SHRT_MAX (32767 - 20000 == 12767 > 20000) will overflow SHRT_MAX (20000 + 20000 == -25536 < 20000) Beim reinen Inkrementieren ist's noch einfacher: ist das Ergebnis 0, dann zweiten Zähler erhöhen: "if (++i1 == 0) i2++;" - natürlich in "schön" :). Denke, dass kann der C-Compiler so optimieren, dass er gar keinen extra "cmp" code generieren muss, weil das zero flag (sofern vorhanden ;)) ja aktuell sein sollte und man (manchmal) eine branch-if-nonzero oder so Assembler Instruktion hat. Sollte dann bei i386 also am Ende auf sowas wie inc eax jnz ok inc [i2] ok: aber seit Jahren kein Assembler mehr gemacht und alles vergessen, Beispiel ist sicher falsch, aber die Idee hoffentlich erkennbar: es ist verdammt schnell. Die Frage ist doch, warum man das (im Kernelcode) so akzeptiert hat. Früher hat man über Windows 49 Tage uptime gelacht, und nu haben wir das bei Linux auch schon...

...

[...] Ja, den Kernel interessiert auch nicht, ob X läuft, also kann man den Computer auch auslassen... (?!)

Hmm, wohl nen Clown gefruehstueckt, was...?

Ja, sorry für den Sarkasmus, aber ist schon klar, dass den Kernel "selbst" das "nicht interessiert", wie ihn überhaupt die uptime nicht interessiert. Sorry, aber ich fand Deinen Hinweis nicht so wirklich produktiv - meiner Meinung nach IST es interessant. Auch andere scheinen diesem Überlauf Wert beizumessen und suchen ihn zu vermeiden, beispielsweise durch Vergrösserung des Datentypes um ein paar Millionen Jahre zu verschieben oder so - es gibt also durchaus Leute, die das interessiert. Da gibts für Linux mindestens patches. Vielleicht hab ich das ein bisschen "persönlich" genommen, weil wir mal ein Problem mit Windows und so einem Überlauf hatten - und zwar genau das "analoge" in Win - und ein Weilchen suchen mussten, um das zu finden. Ein klassisches Beispiel ist ja ein kurzes sleep (warten, bis wert grösser aktueller wert plus 10 ist - klappt natürlich nur, wenn die Overflows zusammen passen bzw nicht passieren). Irgendsowas war da im Code, trat selten auf, hatte aber manchmal Folgen. Hatte den Urprogrammierer in dem Moment wohl auch "nicht interessiert"... oki, teffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

* Thomas Hertweck wrote on Sun, Dec 18, 2005 at 12:01 +0000:

Steffen Dettmer wrote:

...

Hast Du einen Link da, der den Kernel-boot-parameter dokumentiert? Du schriebst ja, der sei SuSE-spezifisch;

[...]

http://portal.suse.com/sdb/de/2003/10/90_scheduling.html,

Ahh, Danke.

Details wirst Du aber dann selbst im Kernel-Source nachlesen muessen, kernel/sched.c koennte ein guter Startpunkt sein...

Ahh, die Dokumentation ist in .c (wie .comment) Files zwischen den geschweiften Klammern :-) Hab jetzt die SuSE 10 Büchse nicht an, aber ich rate mal, dass dieses HZ define durch eine einmalig zu setzende Variable ersetzt wurde. Wobei die uptime dann nicht mehr 100% genu stimmt, sondern eine Abweichung von einigen Millisekunden ergeben kann - was natürlich nicht praxis-relevant ist (wenn man nicht gerade mit emedded Watchdogs arbeitet). [...]

Ich sprach davon (siehe alte Mails), dass man es handhaben kann, aber mit gewissem Overhead. Wenn Du 100 oder 1000 mal pro Sekunde einen Counter erhoehst, und jedesmal, bevor Du das tust, Deine if-Abfrage oben ausfuehren musst, um den Overflow zu erkennen und handhaben zu koennen, also ich nenne so etwas dann ganz gewiss Overhead ;-)

Ja, da stimme ich Dir natürlich grundsätzlich zu, aber man muss ja auch die Verhältnismässigkeit sehen. Wir reden ja hier über einen Interrupt-Handler, der Prozesswechsel "steuert", also "ziemlich teuer" ist, so dass eine schnelle Assemblerinstruktion mehr sicherlich kaum messbar ist. Aber natürlich einen (wenn auch geringen) Effekt hat.

...

[...] Auch andere scheinen diesem Überlauf Wert beizumessen und suchen ihn zu vermeiden, beispielsweise durch Vergrösserung des Datentypes um ein paar Millionen Jahre zu verschieben oder so - es gibt also durchaus Leute, die das interessiert. Da gibts für Linux mindestens patches.

Natuerlich ist es "interessant" (vom Thema her), die Frage ist lediglich, wie praxis-relevant es fuer jeden einzelnen ist. Ich halte es fuer nicht besonders praxis-relevant. Die uptime war auch IMO nie dazu gedacht, dem User-Space eine genaue Zeitrechnung zur Verfuegung zu stellen.

Gut, praxis-relevant oder nicht mag jeder selbst entscheiden; für mich ist es jedenfalls ein Bug, wenn nach 50 Tagen "uptime" einer Workstation behauptet, seit weniger als einem Tag zu laufen - sicherlich aber einer der "unwichtigen und nicht-schlimmen" Bugs. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

Thomas Hertweck wrote:

Jan wrote:

...

Hat jemand eine Idee, warum mein Server nur falsche uptimewerte anzeigt?

Kernel Version 2.4.21-280-athlon Distribution SuSE Linux 9.0 (i586) mail:/~ # uptime 9:54am up 5 days 0:59, 4 users, load average: 0.15, 0.12, 0.05 mail:/~ #

Die Uptime stimmt nicht, die Kiste rennt schon ewig, ohne Reboot. Die User Anzahl ist auch falsch, sind nur 3 drauf.

Der Counter jiffies wird im Kernel HZ mal pro Sekunde erhoeht, wobei HZ vom "desktop" Kernel-Parameter abhaengt. jiffies ist ein "unsigned long" mit einem Wertebereich von 0 bis 4294967295. Teilt man das durch HZ (default: 100) und rechnet es in Tage um, so ergibt sich ein Ueberlauf der Variablen nach 497.103 Tagen und die Uptime beginnt wieder von vorne. Bei Verwendung des desktop-Parameters ist HZ=1000, d.h. der Ueberlauf tritt dann schon nach 49.7103 Tagen auf. Ich nehme an, bei Dir ist einer der beiden Faelle eingetreten...

Also Thomas, Du meinst, sein Rechner läuft ununterbrochen seit ca. 1362 bzw. etwas mehr als 136 Jahren? Ich wußte gar nicht, daß die SuSE 9.0 schon so lange existiert ;-) :-) Martin

K. Elo wrote:

Hallo,

Martin Deppe, 9.12.2005 17:06:

...

Thomas Hertweck wrote:

...

Jan wrote:

...

Hat jemand eine Idee, warum mein Server nur falsche uptimewerte anzeigt?

Kernel Version 2.4.21-280-athlon Distribution SuSE Linux 9.0 (i586) mail:/~ # uptime 9:54am up 5 days 0:59, 4 users, load average: 0.15, 0.12, 0.05 mail:/~ #

Die Uptime stimmt nicht, die Kiste rennt schon ewig, ohne Reboot. Die User Anzahl ist auch falsch, sind nur 3 drauf.

Der Counter jiffies wird im Kernel HZ mal pro Sekunde erhoeht, wobei HZ vom "desktop" Kernel-Parameter abhaengt. jiffies ist ein "unsigned long" mit einem Wertebereich von 0 bis 4294967295. Teilt man das durch HZ (default: 100) und rechnet es in Tage um, so ergibt sich ein Ueberlauf der Variablen nach 497.103 Tagen und die Uptime beginnt wieder von vorne. Bei Verwendung des desktop-Parameters ist HZ=1000, d.h. der Ueberlauf tritt dann schon nach 49.7103 Tagen auf. Ich nehme an, bei Dir ist einer der beiden Faelle eingetreten...

Also Thomas, Du meinst, sein Rechner läuft ununterbrochen seit ca. 1362 bzw. etwas mehr als 136 Jahren? Ich wußte gar nicht, daß die SuSE 9.0 schon so lange existiert ;-)

Nein, er meint ca. 497 Tage, also gut ein Jahr. Tage=[(4294967295/100)/3600]/24

Gruß Kimmo

Tscha, wenn man "," (Komma) meint sollte man auch "," schreiben ;-) Aber mal ernsthaft, ich hätte eigentlich erwartet, daß ein Linux-System damit umgehen können sollte, länger als besagte ca. 1 Jahr und 4 Monate oder gar nur etwa 7 Wochen läuft (ich meine, auch von Seiten der uptime). Gruß Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Hertweck [2005-12-09]:

Martin Deppe wrote:

...

Thomas Hertweck wrote:

...

Der Counter jiffies wird im Kernel HZ mal pro Sekunde erhoeht, wobei HZ vom "desktop" Kernel-Parameter abhaengt. jiffies ist ein "unsigned long" mit einem Wertebereich von 0 bis 4294967295. Teilt man das durch HZ (default: 100) und rechnet es in Tage um, so ergibt sich ein Ueberlauf der Variablen nach 497.103 Tagen und die Uptime beginnt wieder von vorne. Bei Verwendung des desktop-Parameters ist HZ=1000, d.h. der Ueberlauf tritt dann schon nach 49.7103 Tagen auf. Ich nehme an, bei Dir ist einer der beiden Faelle eingetreten...

Also Thomas, Du meinst, sein Rechner läuft ununterbrochen seit ca. 1362 bzw. etwas mehr als 136 Jahren? Ich wußte gar nicht, daß die SuSE 9.0 schon so lange existiert ;-)

Wenn Du nicht in der Lage bist, einen Dezimalpunkt zu erkennen bei dem gewaehlten Font in Deinem MUA, solltest Du vielleicht die Font-Groesse mal aendern. Nur so als Tip, bevor Du Dich noch laecherlich(er) machst ;-)

Nur mal so als Hinweis: Im Deutschen ist der Dezimaltrenner ",". "." ist der Tausendertrenner. Gruß, Bernhard - -- Why use Windows when you can have air conditioning? Why use Windows, when you can leave through the door? -- Konrad Blum -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmeotiGU2lt2vZFQRAm3sAKC3J7faAXUNK2A989OR9Pv45zMqjQCeOsyn wVFi2loRAPlPyAozdkN1w8k= =y0+Z -----END PGP SIGNATURE-----

Thomas Hertweck wrote:

Bernhard Walle wrote:

...

[...]

Nur mal so als Hinweis: Im Deutschen ist der Dezimaltrenner ",". "." ist der Tausendertrenner.

Ich dachte mir schon, dass jemand mit diesem (teilweise) falschen Hinweis kommen wird: es gibt offiziell keinen Trenner von Tausenderstellen! Wenn Du den Punkt so verwendest, ist das reine Gewohnheitssache. Ausserdem lebe ich nicht in Deutschland ;-) Mein urspruengliches Posting war IMHO ziemlich klar und hatte auch eine Erklaerung, so dass es jeder selbst nachrechnen konnte - wer es absichtlich missverstehen will, soll das tun, aber mich bitte damit in Ruhe lassen...

CU, Th.

Soviel dazu, daß man Deinen Rechnungen einfach vertraut ;-) Wie Bernhard schon richtig schrieb, wir sind in Deutschland und dort nimmt man das Komma als Dezimaltrenner, nicht den Punkt. Und wenn Du Dich jetzt angemacht fühlst, tut es mir leid, denn eigentlich war es mehr als kleine Anekdote gedacht gewesen. Aber manch einer kann das vielleicht nicht verstehen. Schade! Cheers Martin

Jan wrote:

Und wo kann ich den wert von 1000 in 100 umstellen? Denn es kommt hin mit 49 Tagen...

Jan, bitte lerne ordentlich zu quoten (kein TOFU!) - siehe Etikette dieser Liste und http://learn.to/quote/. Danke. Mit SuSE 9.0 hielt ein sog. Bootparameter namens "desktop" seinen Einzug. Dieser Parameter aendert das Scheduling-Verhalten des Kernels. Ist der Parameter gesetzt, so werden Time Slices um den Faktor 10 gekuerzt und die Timer Interrupt Frequenz um den Faktor 10 erhoeht. Das soll das Reaktionsverhalten von interaktiven Programmen verbessern, deswegen auch der Name "desktop". Die Standardeinstellung fuer HZ ist 100, d.h. der Counter im Kernel (siehe meine erste Mail) wird 100 mal pro Sekunde erhoeht. Ist der desktop Parameter gesetzt, so ist HZ 1000 und damit laeuft die Counter-Variable auch 10 mal schneller ueber, naemlich bereits nach ca. 49.7 Tagen statt 497 Tagen. Vermutlich ist bei Dir der desktop Parameter in der Bootloader-Konfiguration gesetzt - das ist /boot/grub/menu.lst (GRUB) oder /etc/lilo.conf (LILO). Du kannst als Root den Eintrag aus der Bootloader-Konfig loeschen (nur den desktop Parameter!) und dann rebooten. Solltest Du LILO einsetzen, so musst Du vor(!) dem Reboot den Bootloader neu installieren mit /sbin/lilo. Als Nebenwirkung kann es dann natuerlich passieren, dass Deine interaktiven Programme etwas "traeger" reagieren nach dem Reboot - ob Du das allerdings spuerbar merkst, ist eine andere Frage... CU, Th. PS: Wer Dezimalpunkte statt Kommata findet, darf sie behalten.

Am 10.12.2005 um 21:37 Uhr schrieb Jan Ritzerfeld:

Au contraire! Mein 22. DUDEN (2001) sagt zu Zahlen beim Machinenschreiben und E-Mails Leerschritt oder Punkt. Laut DIN 5008 sollten Leerschritte statt Punkten benutzt werden.

Nur der Vollständigkeit halber: Es gibt seit letztem Jahr eine Neufassung der DIN 5008. Das Dezimaltrennzeichen ist das Komma. Großen Zahlen sollten [1] mit Leerzeichen gegliedert werden, Geldbeträge aus Sicherheitsgründen mit einem Punkt. cu PeeGee [1] "sollte" heißt: es muss so gemacht werden, in begründeten Einzelfällen kann davon abgewichen werden.