by ·Keine Kommentare

Ich musste breit grinsen als ich diesen Text sah:

„I am a Unix Creationist. I believe the world was created on January 1, 1970 and as prophesized, will end on January 19, 2038″

Noch breiter wurde das Grinsen in den Kommentaren. Interessant dass die am lautesten schreien die am wenigsten verstehen was gesagt wurde. :-D

by ·5 Kommentare

Heute habe ich mich (unter anderem) mit einem Problem beschäftigt das auf den ersten Blick trivial aussieht. Ich zumindest habe bislang keine Lösung gefunden die mir wirklich gefällt. Mal sehen ob was dabei rauskommt wenn ich das hier ‚crowdsource’… :-)

Aufgabenstellung: Zähle, wie viele Prozesse eines bestimmten Programmes schon länger als 30 Minuten laufen.

Klingt einfach, oder?

Die Ausgaben von ps zu parsen erscheint mir dabei aber zu fehleranfällig. Da müsste man zu viel berücksichtigen: Prozesse die vielleicht länger als einen Tag laufen, Prozesse die über Mitternacht gelaufen sind… ich habe nicht getestet wie es aussieht wenn man an der Zeitzone rumspielt… Nein, das kann nicht der richtige Ansatz sein.

Meine erste echte Lösung sieht zwar hässlich originell aus, funktionierte aber im Test (zu Demozwecken suche ich mal nach meinem Firefox):

echo | killall -i --older-than 30m firefox 2> /dev/null | tr -cd '?' | wc -c

Mit -i ist killall ‚interaktiv‘, fragt also zu jedem gefundenen Prozess freundlich nach ob es zuschlagen soll. Mit dem reingepipten echo beantwortet es sich diese Frage immer negativ. Der Rest der Zeile zählt im Prinzip wie oft killall gefragt hat ob es töten soll.

Blöd ist, dass die auf einem etwas älteren RHEL laufen soll. Anders als bei Ubuntu kennt killall da die Option –older-than noch nicht.

Der zweite Lösungsansatz funktioniert leider nur auf den ersten Blick, dafür aber auch auf dem alten Red Hat:

find /proc/[0-9]* -maxdepth 1 -name status -mmin +30 | xargs egrep "^Name:\sfirefox$" | wc -l

Ich suche also alle Prozesse die schon länger als 30 Minuten laufen, und suche in deren status-Datei nach dem Namen meines Prozesses. Die Ergebnisse werden dann wieder gezählt. Alternativ könnte man statt in der status- auch in der cmdline-Datei suchen, in meinem echten Einsatz übersehe ich damit dann auch Zombies (die werden separat betrachtet). Leider funktioniert dieser Ansatz nicht wirklich zuverlässig. Es sieht so aus als ob der Kernel den Dateien im Proc-Verzeichnis bisweilen einen neuen Timestamp gibt — obwohl der Prozess nicht gestartet oder beendet wurde. Ein Schuss in den Ofen, also. :-(

Wie macht man sowas? Ich meine, wenn man eine zuverlässige Lösung mit Bordmitteln haben will? Gibt es da ein passendes Tool das ich noch nicht kenne? Oder hilfreiche Optionen für gängige Tools? Wenn ich die Suchmaschine meiner Wahl frage finde ich eine Menge Lösungen, aber die sind entweder auch wackelig, oder sie bestehen darauf direkt alles zu töten…

by ·Keine Kommentare

Kein guter Monat in der IT. Letztes Wochenende ist Dennis Ritchie gestorben. :-(

Er war Miterfinder der Programmiersprache C und des Betriebssystems Unix, und somit vermutlich einer der absolut einflussreichsten Köpfe der Branche. Auch nach mehr als 40 Jahren haben seine Ideen immer noch einen wirklich prägenden Einfluss auf einen Bereich der kaum schnellebiger sein könnte.

Unix und seine Folgen

Unix und seine Folgen

Wer der Ansicht ist damit nichts zu tun zu haben — nicht jeder hat das Privileg mit einem wirklichen Unix arbeiten zu dürfen — mag sich folgendes verdeutlichen:

  • Linux basiert auf den Ideen von Unix.
  • Android enthält einen Linux-Kern, und somit indirekt die Ideen von Dennis Ritchie.
  • Der Kern von Apples MacOS stammt von BSD ab, also von einem echten Unix.
  • Apples iPod, iPhone und iPad enthalten meines Wissens auch einen BSD-basierten Kern.
  • Sogar Windows versucht an einigen Stellen sich an Posix-Standards zu halten, also an die Grundlage von Unix.

Unix is simple and coherent, but it takes a genius ” or at any rate a programmer ” to understand and appreciate the simplicity. (Dennis Ritchie)

Und jedes Mal wenn ich beobachte dass andere Systeme wieder irgendwelche Unix-ähnlichen Features übernommen habe denke ich dan dieses Zitat:

Those who don’t understand Unix are condemned to reinvent it, poorly. (Henry Spencer, Autor von regex)

Ach ja, Ritchie hatte offenbar auch einen ‚besonderen‘ Sinn für Humor:

We stopped when we got a clean compile on the following syntax:

for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

At one time, we thought of selling this to the Soviets to set their computer science progress back 20 or more years.

So zu lesen im Geständnis dass die Idee mit C und Unix eigentlich nur ein Gag gewesen sein sollte — im Jahr 2001. :-D

by ·5 Kommentare

Ich sehe in Sachen Computer gerne mal über den Tellerrand oder in die Geschichte. Einen PC zu programmieren ist ja schon spannend, eigene Programme auf einem Mikrocontroller oder einem HP-42S laufen zu lassen ist aber ein echtes Abenteuer. Sich da rein zu denken ist wie das Eintauchen in eine andere Welt.
Eine Plattform mit der ich immer schon mal spielen wollte ist die PDP-11. Ein echtes Stück Technikgeschichte. Dementsprechend begeistert sehe ich mir gerade einen Emulator an. Geschrieben in… Javascript! In dem Emulator kann man ein Unix starten und benutzen. Emuliert wird auf Hardware-Ebene, mit dem Ding sollte sich also praktisch alles machen lassen was man auch mit der originalen Maschine machen konnte. Wenn auch die Haptik natürlich fehlt…
Ein paar Widrigkeiten der Emulation klärt die FAQ, leider weiß ich aber noch nicht warum alles elendig langsam ist. Klar fühlt sich Technik aus den 70ern anders an als aktuelle, trotzdem habe ich das Gefühl dass das entweder an meiner Hardware oder — wahrscheinlicher — an meiner dünnen Leitung liegt. Ist das überall so langsam?

by ·Keine Kommentare

Dass man Passworte und ähnlich vertrauliche Sachen nicht in Kommandozeilen verwenden sollte ist mir klar. Jeder der auf dem gleichen System angemeldet ist kann sich mittels ‚ps auxwww‘ den vollständigen Aufruf anzeigen lassen, einschließlich womöglich benutzter Passworte.

Bisher hätte ich in meinem jugendlichen Leichtsinn aber keine Bedenken gehabt, solche Daten in Umgebungsvariablen zu hinterlegen. Klar, irgendwo unter /proc findet man die soweit ich weiß auch wieder. Aber nur wenn man root ist, oder wenn man Spaß daran hat, seine eigenen Prozesse zu bespitzeln. Fremde Prozesse kann man so nicht einsehen.

Es geht aber auch anders: mit ‚ps auxwwwe‘ — das ‚e‘ steht offenbar für ‚Environment‘ — stehen auch Umgebungsvariablen in der Prozessliste. Für alle Benutzer auf dem gleichen System einsehbar, ohne dass die über besondere Rechte verfügen müssen.

Man lernt nie aus… Und nachdem ich das jetzt weiß werde ich erstmal gründlich in mich gehen um rauszufinden wo ich eventuell solche Leichen im Keller habe… :-(

by ·Keine Kommentare

Naja, ganz so dramatisch muss man das vielleicht nicht ausdrücken. Aber ab Morgen (Samstag) sind es nur noch 30 Jahre bis zum gefürchteten Y2K38-Bug, bei dem Unix-Systeme Probleme mit der Zeitzählung kriegen können.

(Ja, ich weiß auch dass viele Systeme bereits jetzt Gegenmaßnahmen ergriffen haben, und man sich 2038 wahrscheinlich mehr Sorgen darum macht dass die Grafikkarte nicht für Duke Nukem Forever reicht… ;-) )