Private Homepage von Michael MeßPrivate Homepage von Michael Meß - Linux - FAQPrivate Homepage von Michael Meß
Michael Meß
Hobbies
Sonstiges
Links
Impressum
Linux
Linux Tuning
Linux FAQ
Software - Download
Rudern
Schach

Linux FAQ - Probleme und Lösungsvorschläge

Jedesmal, nachdem ich Linux benutzt habe, ist auf meinem Rechner das Datum 1.1.1997 und 0:00 Uhr

Mögliche Ursache:
Wahrscheinlich ist der Rechner ein SMP-System (SMP=Symmetric Multi Processor, Ein Rechner mit mehreren Prozessoren) und der Kernel hat keinen RTC Support eincompiliert. Dann wird irgendwo mit /sbin/hwclock auf die Hardware-Zeit (CMOS-Clock) zugegriffen, was das Übel dann auslöst. Wenn kein /dev/rtc existiert, greift /sbin/hwclock als root direkt auf die Hardware zu, was nicht dem Standard entspricht, wobei dann die Zeit im CMOS ungültig wird und beim nächsten Booten vom BIOS dann auf den 1.1.1997 und 0:00 zurückgesetzt wird.
Lösungsvorschlag:
Im Linux-Kernel unter Character-Devices Enhanced-Real-Time-Clock-Support aktivieren. Dann benutzt /sbin/hwclock das Device /dev/rtc, um auf die CMOS-Zeit zuzugreifen, wie es dem Standard entspricht, so daß das Problem nicht mehr auftauchen sollte.
Anmerkung:
Man sollte das Programm so ändern, daß es nur /dev/rtc benutzt oder eine Fehlermeldung ausgibt, die auf eine Kommandozeilenoption hinweist. Soll es wirklich direkt auf die Hardware zugreifen, so sollte es dies nur per Kommandozeilenoption tun.

Ghostscript macht Probleme, wenn es in einer Pipe verwendet wird

Symptom:
Beim Drucken werden bei bestimmten Dateien leere Seiten oder Seiten mit irgendwelchem Unsinn gedruckt, manchmal bricht der Ausdruck einfach ab.
Ursache:
Der Output von Ghostscript wurde auf stdout geleitet, um ihn in einer Pipe weiterzuverarbeiten. Leider kommt es hin und wieder vor, daß Ghostscript trotz "-q" oder "Quiet"-Option unerwünscht Warnungen oder Fehlermeldungen ausgibt und diese auf stdout schreibt. Dieses vermischt sich dann mit dem Output und verunreinigt diesen damit, was dann das Problem verursacht.
Leider bietet Ghostscript keine Möglichkeit, Warnungen und Fehlermeldungen auf stderr auszugeben, so daß sie sich nicht mit dem Output auf stdout mischen können.
Lösung
Ghostscript bietet die Möglichkeit an, den Output von sich aus direkt in eine Pipe zu leiten. Diese können wir dazu nutzen, um den Output, der dort sauber in stdin ankommt auf stderr auszugeben. Wir bekommen dann den Output in stderr und die Warnungen landen wie immer auf stdout. Die Warnungen werfen wir in die Mülltonne (/dev/null) und leiten anschließend stderr wieder nach stdout um, so daß wir am Ende den reinen Output (ohne Verunreinigungen) in einer Pipe weiterverarbeiten können.
Das sieht dann so aus: (Achtung, die Anführungszeichen um "-sOutputFile" und "cat" herum sind wichtig!)
(gs  -sDEVICE=pswrite -dNOPAUSE -q -dSAFER 
-dBATCH '-sOutputFile=|bash -c "cat 1>&2"'  /tmp/printpreview.ps 1> /dev/null ) 2>&1

Zur Erklärung: Ghostscript ruft die Shell bash auf, um in ihr das Kommando "cat 1>&2" auszuführen. Das "cat" macht nichts anderes, als den Ghostscript-Output von stdin einzulesen und auf stdout wiederzugeben. "1>&2" bedeutet, daß der Output des cat-Kommandos von stdout umgeleitet wird nach stderr. Das zusammen bewirkt also, daß der Output von Ghostscript auf stderr landet. Da Ghostscript stderr nicht nutzt und die Warnungen und Fehler alle auf stdout landen, ist es so möglich, den Output von den Warnungen getrennt und unversehrt zu erhalten. Die Warnungen auf stdout von Ghostscript leiten wir mit "1> /dev/null" in den Mülleimer - es bleiben die Nutzdaten auf stderr, die wir dann außerhalb der Klammer wieder auf stdout umleiten, wo sie ja eigentlich hingehören.
Anmerkung:
Daß eine Anwendung Warnungen standardmäßig auf stdout ausgibt und man diese nicht mit 100%iger Sicherheit unterdrücken kann ist eine große Schwäche von Ghostscript. Was haben sich die Programmierer eigentlich dabei gedacht? Ich denke, daß es einfach zum Standard gehört, daß Warnungen auf stderr gehören und Nutzdaten auf stdout - als Kompatibilitätsmaßnahme könnte man ja im Fall von Ghostscript eine Option anbieten, die derzeitige Konfiguration mit Warnungen auf stdout per Kommandozeilenparameter oder per Environment-Variable einzustellen. Wer es dann wirklich so braucht, kann es dann auch so haben, obwohl ich glaube, daß nur Wenige das so wirklich brauchen.