Drucksystem verschluckt Jobs
Hallo,
Nach stundenlanger erfolgloser Fehlersuche bin ich jetzt hier auf der
Mailingliste gelandet und hoffe, mir kann jemand helfen.
Zum System:
Epson Stylus Color 400 an paralleler Schnittstelle, Debian Woody,
lpr Version 2000.05.07-4.3, apsfilter Version 7.2.2-3, gs Version
6.53-3
Problem:
Nachdem ich gestern morgen noch drucken konnte, geht seit gestern
nachmittag /nichts/ mehr. Druckjobs werden vom System einfach
verschluckt ohne brauchbare Fehlermeldung. Zwischendurch habe ich
"lediglich" per apsfilterconf neue Warteschlangen eingerichtet.
Ein Löschen aller Spoolverzeichnisse in /var/spool/lpd/, der
Konfigurationsdatei /etc/printcap sowie des Verzeichnisses
/etc/apsfilter (mit Ausnahme des SymLinks basedir) und
anschließendes Neuaufsetzen des Drucksystems brachte keine Abhilfe.
Am besten, ich "verfolge" mal einen Druckjob und zeige, was passiert:
> lpr -Pesc-draft vermerk.ps
> ps ax
7479 ? S 0:00 /bin/bash /etc/apsfilter/basedir/bin/apsfilter -w132 -l66 -i0 -n rob -h oberon /var/spool/lpd/esc-draft/acct
7497 ? S 0:00 /bin/bash /etc/apsfilter/basedir/bin/apsfilter -w132 -l66 -i0 -n rob -h oberon /var/spool/lpd/esc-draft/acct
7498 ? S 0:00 /bin/bash /etc/apsfilter/basedir/bin/apsfilter -w132 -l66 -i0 -n rob -h oberon /var/spool/lpd/esc-draft/acct
7499 ? S 0:00 /bin/bash /etc/apsfilter/basedir/bin/apsfilter -w132 -l66 -i0 -n rob -h oberon /var/spool/lpd/esc-draft/acct
7500 ? S 0:00 /bin/bash /etc/apsfilter/basedir/bin/apsfilter -w132 -l66 -i0 -n rob -h oberon /var/spool/lpd/esc-draft/acct
7501 ? S 0:00 /bin/sh -e /usr/bin/psset -n -q -s
7502 ? R 0:00 gs -q -dNOPAUSE -dSAFER -dPARANOIDSAFER @stcany.upp -sPAPERSIZE=a4 -sOutputFile=- -
> lpq -a
> tail -n 1 /var/spool/lpd/esc-draft/log
apsfilter warning: unknown option 'oberon'
> cat /var/spool/lpd/esc-draft/status
esc-draft is ready and printing
> ps ax | grep aps
7596 pts/6 S 0:00 grep aps
> tail -n 1 /var/log/lpr.log
Apr 23 00:13:55 oberon lpd[29239]: restarted
> tail -n 1 /var/log/lp-errs
> tail -n 1 /var/log/lp-acct
>
Ich hatte noch ein "tail -f /var/spool/lpd/esc-draft/log" laufen und dabei
bemerkt, daß die Statusleuchte des Druckers kurz blinkt, wenn diese Meldung
im Logfile erscheint. Ansonsten regt sich am Drucker nichts.
Bei den anderen Warteschlangen habe ich exakt das gleiche Problem; kurz
nach Einrichtung der Warteschlangen mittels apsfilterconf konnte ich noch
auf esc-draft drucken (eine Seite) - danach ging nichts mehr.
Die Warnung, die apsfilter oben ausgibt, kann auch schon vorher da gewesen
sein und muß nicht das Problem sein (ist ja "nur" eine Warnung). Allerdings
habe ich versucht, ihre Ursache zu finden und bin mir nicht ganz klar, ob
es nicht ein Fehler im Kommandozeilen-Parser von apsfilter ist. Denn die
Option "-h HOST" ist korrekt so. Und die Fehlermeldung wird ein ganzes
Stückchen nach dem Parsing auf "-h HOST" erzeugt - dort wo eine ganz andere
Form von Parametern dran ist (einfach mal apsfilter mit less ansehen).
Dann wundert mich noch, daß apsfilter mindestens fünf mal aufgerufen wird
- ist das normal so?
Hier noch ein Ausschnitt aus /etc/printcap:
------------------------------------------------------------
# APS3_END - don't delete this
# APS4_BEGIN:printer4
# - don't delete start label for apsfilter printer4
# - no other printer defines between BEGIN and END LABEL
esc-draft|stcany.upp;r=180x180;q=draft;c=gray;p=a4;m=auto:\
:lp=/dev/lp0:\
:if=/etc/apsfilter/basedir/bin/apsfilter:\
:sd=/var/spool/lpd/esc-draft:\
:lf=/var/spool/lpd/esc-draft/log:\
:af=/var/spool/lpd/esc-draft/acct:\
:mx#0:\
:sh:
# APS4_END - don't delete this
------------------------------------------------------------
Ein echo TEST > /dev/lp0 erzeugt übrigens die gewünschte Wirkung und auch
das Verwenden anderer Treiber (stp/escp2-400 statt stcany.upp) brachte
keinerlei Abhilfe.
Weiß jemand, was hier schiefläuft?
Vielen Dank schonmal,
Robert Jäschke
--
"I have been a happy man ever since January 1, 1990, when I no longer had an
email address. I'd used email since about 1975, and it seems to me that 15
years of email is plenty for one lifetime."
--- Donald E. Knuth (http://www-cs-faculty.stanford.edu/~knuth/email.html)
Reply to: