Uptimes (war: Re: Wie USB Drucker in CUPS (automatisch) aktivieren?)
Am Dienstag, 17. Juli 2012 schrieb Michelle Konzack:
> Hello Martin Steigerwald,
>
> Am 2012-07-16 23:53:24, hacktest Du folgendes herunter:
> > Also automagisch hab ich das noch nicht gesehen. Ich gehe auf
> > localhost:631, sage neuen Drucker, wähle den vorher eingeschalteten
> > USB- Drucker und klicke dann „Weiter“, „Weiter“, „Weiter“.
>
> Habe gerade gesehen, das der Fehler ein Resultat des dist-upgrades
> war und ich die Kiste noch garnicht neu gebootet habe -- seit 6 1/2
> Tagen!
>
> --[ command 'uprecords -B -m 20'
Soso, also hast Du dolle Uptimes. Ich erspare uns hier einen Vergleich mit
Uptimes, die ich mit TuxOnIce-Kerneln gesehen habe, außer, dass ich auch
schon Monate mit ein und derselben KDE-Sitzung gearbeitet habe.
Du bist wertvoll – unabhängig von den Uptimes Deiner Workstations.
Ich hab uptimed gerade von meinem Haupt-Notebook entsorgt, nachdem es
wieder mal irgendwie die Datenbank geschrottert hat. Debian-Maintainer und
Autor weigern sich, das Teil mit fsync()-Semantik für Dateisysteme mit
Delayed Allocation Crash Proof zu machen und den von mir getestete und
erst für gut befundene Workaround, die records-Datei dann zumindest mit
einer Null-Byte-Backup-Datei zu überschreiben, greift wohl auch nicht
richtig oder es ist noch ein andere Bug drin. Ich hab auf einem Laptop
auch schon eine negative Gesamt-Uptime gesehen. Also glaub ich schon, dass
da noch mehr Bugs drin sind, hab aber keinen Nerv mehr mit Maintainer oder
Upstream-Autor zusammenzuarbeiten. fsync() sei auf Ext3 zu langsam, auf
anderen Unixen garantiere fsync() gar nicht, dass die Datei auf Platte
ist, für ein System, das auch mal abstürzt oder wo der Strom ausfällt, sei
uptimed nicht geschrieben usw. usf. Durchaus Argumente, die ich
nachvollziehen kann, für mich mach uptimed auf Desktops und Notebooks aber
nur Sinn, wenn es nicht alle paar Monate die Statistik zerhaut.
Einzig auf meinem virtuellen Server scheint es bislang zu passen, da der
läuft halt einfach nur.
Soweit ich gesehen hab, ist das Teil auf einem System, wo auch mal ein
Test-Kernel crasht, oder ich den Akku rausziehe, während das Netzteil doch
nicht mit Strom versorgt war schlicht zu unzuverlässig, um zumindest
einigermaßen akkurate Statistiken zu erstellen.
Ich hab ein paar Ideen, wie das zuverlässiger funktionieren könnte. Ich
würde zur Lautzeit immer regelmäßig nur ein touch auf eine Datei, die
Kernel-Version, ggf. eine Boot-Id und den Bootzeitpunkt enthält,
ausführen. Denn so ein touch ist immer atomisch. Entweder die Zeit ist
aktualisiert oder die alte Zeit ist zumindest noch da.
Bei einem Neustart würde ich die Boot-Zeiten-Tabellen anhand der letzten
Datei(en) dieser Art aktualisieren und dann nach allen Regeln der Kunst
mit fsync() hinterherwerkeln und erst dann diese Touch-Dateien entfernen.
Und ob dann ein x-beliebiges BSD die gleichen Garantien bietet, wär mir
dann sowas von egal.
Aber bis ich mal dazu komme, sowas zu schreiben, habe ich mich zumindest
was mein Haupt-Notebook getroffen zur Entscheidung durchgerunfen, uptimed
einfach zu entsorgen, anstatt die records-Datei von Hand aus rdiff-backup-
Kopien von Hand hinzubasteln und Ähnliches.
Ein heilsamer Schritt, wo ich doch selbst immer wieder so uptime-geil war.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: