|
Eine Woche für drei Zeilen
|
 Geschrieben von Beat Rubischon am
Samstag, 5. November 2005, 18:00
aus dem eine-woche-im-leben dept.
Dass Computer Aerger machen, das wissen wir wohl alle. Aber für wirklichen Frust braucht man einen Printer. Letzte Woche habe ich einen grossen Teil meiner Arbeitszeit mit einem solchen verlölt und möchte hier darüber berichten - vielleicht als Abschreckung für all diejenigen, die Informatiker als Traumjob betrachten?
Wir sind unter anderem verantwortlich für das Funktionieren einer hand voll Printer. Seit vielleicht zwei Jahren beobachten wir gehäuft Crashes dieser Drucker. Nachdem ich letzte Woche Helldesk machte und einen grossen Teil meiner Zeit in eben diese Crashes investieren musste, setzte ich mir am Montag Morgen das Ziel, der Ursache dieser Probleme auf den Grund zu gehen.
Für den Rest der Woche machte ich nicht viel anderes. Tonnenweise Arbeit blieb liegen, die ganze Woche kam ich nie ins Training und die Abende über war ich eher genervt als ein guter Vater und Ehemann. Ich mag Jobs, die einen klaren Lösungsweg haben, bedeutend lieber. Aber die sind nicht immer zu haben und die Lösung solcher Probleme scheinen leider über 20 Jahre Erfahrung mit zickenden Geräten zu bedingen...
Ein Problem war sicherlich das Netz. Wir hatten bis Anfangs Jahr alle Printer mit Public IPs. Die Qualität der Netzwerkstacks einer typischen Ethernetkarte für Printer ist nicht sonderlich gut - bis zum totalen Ausfall der Karte haben wir alles erlebt. Dies hat massiv gebessert, seit die Printer mehrheitlich in einem privaten Netz liegen und nicht mehr erreichbar sind. Aber weg waren die Crashes noch immer nicht.
Was dann? Mir blieb nichts anderes übrig, als alle Printjobs aufzubewahren und einen häufig betroffenen Printer per WebJetAdmin zu monitoren. Sobald es knallte, die Queue auseinandernehmen und die Jobs zur Analyse wegsichern.
Etwa Donnerstagabend war ich so weit, dass ich einen effektiven Weg zum Crash eines Druckers gefunden hatte: Man nimmt ein paar EPS Files und bindet diese in ein TeX Dokument ein. Um Papier zu sparen, schickt man das Dokument durch psnup um zwei oder vier Seiten auf ein Blatt Papier zu drucken.
Die mehrfach vorkommenden showpage kommen sich ins Gehege. Faszinierenderweise kann man das Dokument problemlos in gs oder gv betrachten, jedoch nicht mehr ausdrucken. Gewisse Dokumente kommen aus dem Printer, aber der Folgejob crasht - gewisse Dokumente printen mehrere Seiten übereinander - gewisse Drucker verschlucken den Job einfach. Auch bei den Printern sind die Unterschiede der Qualität der Postscript Engines gewaltig - und der Preis ist nicht immer Massstab für die Qualität.
Gestern Nachmittag war ich so weit, dass der Workaround stand. Wir haben auf unseren Linux-Workstations einen Wrapper rund um lpr, in dem nun zusätzlich folgender Kommand steht:
gs -dNOPAUSE -dBATCH -dSAFER -q -sOutputFile=- \
-sDEVICE=pswrite -dLanguageLevel=1 \
-sPAPERSIZE=a4 -r600x600 -
Damit werden nun die Files erst "gereinigt", bevor sie weiterverarbeitet werden. Ach ja, Level2 crashte wiederum auf gewissen Printern, daher die Option um Level1 zu erzeugen... Der Aufwand ist nicht zu vernachlässigen, aber über diesen Weg sind die Benutzer von Windows, MacOS und Cups-fähigen Applikationen unter Linux nicht betroffen.
Nächste Woche heisst es warten und sehen. Wenn das der einzige Fehler war, dann können wir aufatmen. Wenn nicht, warten noch mehr solch nervenaufreibende Tage auf mich.
Permalink
|
|
|