CUPS-daemon Suse8.2 blockiert /dev/lp0
Habe hier ein ganz kniffelige Problem: sporadisch scheint der cupsd /dev/lp0 zu blockieren oder zu verzögern um 10-30 Sekunden. Hat jmd ähnliche Erfahrungen mit dem cups-daemon? (Suse 8.2 hat cups-1.1.18 drauf) Dagegen gibt es bei Verwendung des cups-Drucksystemes, das mit Yast konfigurierbar ist, weniger Probleme. Allerdings kommt Yast, weil er ständig die cups- Datenbank aktualisiert schon mal in eine Endlosschleife und es ist gar keine Druckerkonfiguration mit Yast mehr möglich (siehe viele Monate alter thread von mir). Daher hatte ich mit Verwendung des cupsd (rccups start, insserv cups) den Yast umgangen. Seitdem toben aber die Verzögerungs- bzw Blockierungsprobleme mit dem cupsd (=cups-daemon). Die Probleme bestehen, auch wenn keine Warteschlage auf /dev/lp0 eingerichtet ist. Ich brauche leider wegen einem speziellen Linux- Programm, das seine eigenen Treiber hat, /dev/lp0. Der cupsd hat mit raw-Warteschlagen nämlich besonders Probleme. Vielleicht wegen bestimmter Steuerzeichen in dem Druckfile. Das Problem mit raw-Druckaufträgen wird cups allgemein nachgesagt. Daß cupsd nun auch noch den /dev/lp0 gelegentlich ausschaltet, obwohl gar nicht benutzt, ist nun meine Vermutung. Eigentlich will ich den cupsd lieber als Yast- Druckerkonfiguration, weil elegant über localhost:631 konfigurierbar. Aber wenn der cupsd die /dev/lp0 von PC lahmlegt, ... dann ...? danke schonmal Ekkard
Hallo, On May 27 12:17 Ekkard Gerlach wrote (shortened):
Daher hatte ich mit Verwendung des cupsd (rccups start, insserv cups) den Yast umgangen. Seitdem toben aber die Verzögerungs- bzw Blockierungsprobleme mit dem cupsd (=cups-daemon). Die Probleme bestehen, auch wenn keine Warteschlage auf /dev/lp0 eingerichtet ist.
Wenn der cupsd startet ruft er jedes vorhandene Backend auf, siehe z.B. "Die Backends" in: http://portal.suse.com/sdb/de/2004/05/jsmeix_print-cups-in-a-nutshell.html Wenn ein Backend nicht benötigt wird, kann es gelöscht oder aus dem Verzeichnis irgendwohin wegbewegt werden. Gruss, Johannes Meixner -- SUSE LINUX AG, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
Am Donnerstag, 27. Mai 2004 13:45 schrieb Johannes Meixner:
http://portal.suse.com/sdb/de/2004/05/jsmeix_print-cups-in-a-nutshell.html
Wirklich schöner Artikel übrigens,- Danke! Gruß Harald
* Johannes Meixner schrieb:
http://portal.suse.com/sdb/de/2004/05/jsmeix_print-cups-in-a-nutshell.html schöner ARtikel ..
Wenn ein Backend nicht benötigt wird, kann es gelöscht oder aus dem Verzeichnis irgendwohin wegbewegt werden.
wie aber mache ich cups klar, daß er lp0 wohl benutzen , aber lp1 in Ruhe lassen soll? - Es ist eine zweite Parport-PCI im PC. drwxr-xr-x 2 ... 4096 Oct 7 2003 ./ drwxr-xr-x 6 ... 4096 Sep 30 2003 ../ -rwxr-xr-x 1 .. 13878 Mar 17 2003 canon* -rwxr-xr-x 1 ...13907 Mar 17 2003 epson* lrwxrwxrwx 1 ... 3 Sep 30 2003 http -> ipp* -rwxr-xr-x 1 ... 16572 Mar 17 2003 ipp* -rwxr-xr-x 1 ... 14300 Mar 17 2003 lpd* -rwxr-xr-x 1 ... 1673 Mar 17 2003 novell* -rwxr-xr-x 1 ... 8444 Mar 17 2003 parallel* -rwxr-xr-x 1 ... 1042 Mar 17 2003 pipe* -rwxr-xr-x 1 ... 6332 Mar 17 2003 scsi* -rwxr-xr-x 1 ... 9080 Mar 17 2003 serial* lrwxrwxrwx 1 ... 17 Oct 7 2003 smb -> /usr/bin/smbspool* -rwxr-xr-x 1 7688 Mar 17 2003 socket* -rwxr-xr-x 1 ... 10612 Mar 17 2003 usb* Gruss Ekkard
Hallo, On May 27 16:54 Ekkard Gerlach wrote (shortened):
wie aber mache ich cups klar, daß er lp0 wohl benutzen , aber lp1 in Ruhe lassen soll? - Es ist eine zweite Parport-PCI im PC.
Entweder im CUPS Quellcode am "parallel" Backend rumpatchen und CUPS neu bauen, wenn man sowas gerne tun mag, oder für diesen Spezialfall ein eigenes Backend für den ersten Parallelport machen und das "parallel" Backend wegbewegen. Vorschlag für ein einfaches /usr/lib/cups/backend/lp0 Backend: ------------------------------------------------------------------- #! /bin/bash # see the "CUPS Software Programmers Manual": # "Writing Filters" and "Writing Backends" # debug info in /var/log/cups/error_log set -x # output "Device Discovery" information on stdout if [ "$#" -eq "0" ] then echo 'direct lp0 "Unknown" "lp0 Printer"' exit 0 fi # have the input at fd0 (stdin) in any case if [ -n "$6" ] then exec <"$6" fi # infinite retries to access the device until cat /dev/null >/dev/lp0 do echo 'INFO: cannot access /dev/lp0 - retry in 30 seconds' 1>&2 sleep 30 done echo 'INFO: sending the data to /dev/lp0' 1>&2 # forward the data from stdin to the device if cat - >/dev/lp0 then echo 'INFO:' 1>&2 exit 0 else echo 'ERROR: failed to send the data to /dev/lp0' 1>&2 exit 1 fi ------------------------------------------------------------------- cupsd stoppen und starten, dann mit "lpinfo -v" prüfen, ob der cupsd das Backend "lp0" kennt, dann z.B. mit "lpadmin ... -v lp0 ..." eine Warteschlange anlegen bzw. damit die DeviceURI für eine bestehende Warteschlange ändern. Gruss, Johannes Meixner -- SUSE LINUX AG, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
* Johannes Meixner schrieb:
Entweder im CUPS Quellcode am "parallel" Backend rumpatchen und CUPS neu bauen, wenn man sowas gerne tun mag, oder für diesen Spezialfall ein eigenes Backend für den ersten Parallelport machen und das "parallel" Backend wegbewegen.
Vorschlag für ein einfaches /usr/lib/cups/backend/lp0 Backend: ------------------------------------------------------------------- #! /bin/bash # see the "CUPS Software Programmers Manual": # "Writing Filters" and "Writing Backends"
# debug info in /var/log/cups/error_log set -x
[...] habe mal gekürzt. Habe diesen Code anstelle des /usr/lib/cups/backend/parallel eingesetzt. Es funktioniert schonmal, daß bestehende Warteschlagen, die auf parallel konnektiert waren, auch weiterhin auf lp0 drucken. Das mit der Idee das Skript mit lp0 zu bennenen verstehe ich nicht, CUPSd kann dann den lp1 immer noch blockieren, oder? Genau das will ich ja vermeiden! Das cups-html-Frontend zeigt nun nur noch "lp0" als device an und nicht mehr parallel#0 und parallel#1. Wähle ich es aus, dann bekomme ich eine Aufforderung eine remote-Warteschlange anzusteuern: Device URI: Examples: file:/path/to/filename.prn http://hostname:631/ipp/ http://hostname:631/ipp/port1 ipp://hostname/ipp/ ipp://hostname/ipp/port1 lpd://hostname/queue smb://workgroup/server/sharename socket://hostname socket://hostname:9100 .. was ja nicht so sein sollte. Ich will ja schon noch per CUPS auf lp0 konfigurieren können. Fehlt in Deinem Skript noch irgendwas, damit cups-html-Frontend weiß, daß /dev/lp0 gemeint ist? Aber gut, zu Konfigurieren das originale "parallel" wieder hineinkopiert und dann wieder zurück. Ich werde es gleich bei Kunden testen, morgen abend werde ich wissen, ob lp1 mit diesem Skript wirklich "frei" geworden ist und die Druck-Verzögerungen ausbleiben. Bei mir hier ist schon alles getestet, aber die Verzögerungen treten ja nur beim Kunden sporadisch auf, bei mir nie.
cupsd stoppen und starten, dann mit "lpinfo -v" prüfen, ob der cupsd das Backend "lp0" kennt,
lpinfo -v liefert: [...] direct lp0 network lpd network novell direct canon:/dev/lp0 [...] direct stimmt, denke ich. Aber beim lp0 fehlt noch ein /dev/ davor, oder? Sorry, ich verstehe Dein Skript nicht sonderlich, daß ich es selber finden könnte.
dann z.B. mit "lpadmin ... -v lp0 ..." eine Warteschlange anlegen bzw. damit die DeviceURI für eine bestehende Warteschlange ändern.
uff .. noch nie gemacht. Muß ich es damit machen? Gruss Ekkard
Hallo, On May 31 18:08 Ekkard Gerlach wrote (shortened):
Das mit der Idee das Skript mit lp0 zu bennenen verstehe ich nicht,
Wie das Skript heisst ist völlig egal, ausser dass es seinen Namen auszugeben hat, wenn es ohne Parameter direkt aufgerufen wird (siehe unten).
CUPSd kann dann den lp1 immer noch blockieren, oder? Genau das will ich ja vermeiden!
Wenn das parallel Backend wegbewegt wurde, nicht mehr. Ausserdem ist es nicht der cupsd, der irgendwas falsch macht, sondern der zweite Parallelport ist falsch konfiguriert bzw. die Hardware ist fehlerhaft oder das Gerät was daran hängt macht etwas falsch, verhält sich evtl. nicht IEEE 1284 konform oder was weiss ich was da die eigentliche Ursache ist. Daher der Workaround im Drucksystem mit dem Skript.
Das cups-html-Frontend zeigt nun nur noch "lp0" als device an und nicht mehr parallel#0 und parallel#1.
Gut.
Wähle ich es aus, dann bekomme ich eine Aufforderung eine remote-Warteschlange anzusteuern:
Device URI: Examples: file:/path/to/filename.prn http://hostname:631/ipp/
Egal. Da ist wohl die Eingabemaske des Web-Frontends recht pingelig. Einfach z.B. lp0:/foo eingeben um der Syntaxprüfung des Web-Frontends zu genügen oder etwas hübscher im Skript # output "Device Discovery" information on stdout if [ "$#" -eq "0" ] then echo 'direct lp0:/dev/lp0 "Unknown" "lp0 Printer"' exit 0 fi eintragen, aber es ist wirklich egal, ob da "lp0:/dev/lp0" oder "lp0:/foo" ausgegeben wird, Hauptsache die URI fängt mit dem Namen des Scripts an, denn das eigentliche Ausgabedevice /dev/lp0 ist im Skript hart codiert. Es ist eben ein recht simples Skript, aber als Workaround sollte es genügen. Mit obiger Änderung im Skript ist dann auch das Web-Frontend zufriedengestellt. Ich hatte es nur mit "lpadmin" getestet.
... die Verzögerungen treten ja nur beim Kunden sporadisch auf, bei mir nie.
Klar. Es liegt ja eigentlich am Parallelport des speziellen Rechners. Aber wenn man es da nicht beheben kann, muss man eben auf Seiten des Drucksystems das Problem umgehen. Gruss, Johannes Meixner -- SUSE LINUX AG, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
participants (3)
-
Ekkard Gerlach -
Harald_mail＠t-online.de -
Johannes Meixner