Johannes Meixner schrieb:
Hallo,
On Dec 1 13:40 Joerg Thuemmler wrote (shortened):
wenn ich einen "langen" Druckauftrag an einen direkt (lp0) angeschlossenen raw-Drucker schicke, steigt dieser nach knapp 2 Stunden (die Zeit mag schwanken, aber in dieser Größenordnung) grußlos aus.
Wieso "grußlos"? Es ist doch im Log alles recht gut dokumentiert.
korrekt. Ich meinte eher, weil auch bei lpr -VVV ... keine Fehlermeldung kommt
subserver pid 28995 starting at 2004-12-01-09:54...
...
finished 'xdvs@linux+993', status 'JTIMEOUT' at 2004-12-01-11:34...
...
warum tut der das???
Weil es bei LPRng für (fast) alles eine Einstellmöglichkeit gibt und die Voreinstellungen eben dementsprechend sind. (Ein Fragezeichen genügt.)
Oder gibt es generell eine Timeout-Einstellung für den lpr.
Beim LPRng gibt es keine generelle Timeout-Einstellung, sondern etliche Timeout-Einstellungen.
Wenn man LPRng auch für Sonderfälle selbst administrieren möchte, muss man das LPRng-HOWTO einmal komplett lesen, denn es gibt dermassen viele Einstellmöglichkeiten, dass man das passende kaum auf die Schnelle findet.
Ich weiss jetzt auch keine Lösung sofort aus dem Kopf, aber mir scheint send_job_rw_timeout der eigentlich interessante Parameter zu sein, den der steht meiner Erinnerung nach per Default auf 6000 Sekunden (siehe "man printcap") was perfekt zu obigem Log passen würde: starting at 09:54 ... 'JTIMEOUT' at 11:34
send_job_rw_timeout findet man noch relativ leicht, wenn man nach "timeout" im LPRng-HOWTO sucht.
Gruss, Johannes Meixner
Danke, ich denke send_job_rw_timeout wird es sein. Ich hatte das im Howto auch gefunden, es aber nur so verstanden, daß es bestimmt, wie lange der lprng versucht, ein Ausgabegerät zum Schreiben zu öffnen oder Daten zu senden, nicht, daß es den job selbst kontrolliert. Deshalb dachte ich, wenn der Druck einmal läuft, kann ein so langes timeout kaum auftreten, denn der Drucker sendet ja immer nach ein paar sec ein Ready und kriegt neue Daten. Muß das Howto nochmal in Ruhe lesen, hatte bis auf diesen Fall keinen Ärger mit lprng, der mit meinen verschiedenen Clients recht gut klarkommt, bei lprold, den ich bis voriges Jahr im Einsatz hatte, trat der Fehler definitv nicht auf. Danke für die Aufhellung im recht dunklen Dezember! -- Joerg Thuemmler listen@vordruckleitverlag.de