Hallo, Es ist einfach so, das auch nach über 10 Arbeitsstunden der Drucker nicht funktioniert, da er aber von einer VB auf dem selben Rechner läuft, ist der Drucker ok und auch der Rechner ok. Es ist aber so, das jedes Jahr ca. 10% der Druckerinstallationen mit CUPS zu unlösbaren Problems führen. Die einzige Möglichkeit ( ich will das nicht Lösung nennen) , die dann meistens funktioniert, ist, alle Daten zu sichern, den betreffenden Rechner komplett neu zu installieren und dann läuft der Drucker meistens. Das ist natürlich alles andere als schön, aber anscheinend unvermeidbar. Zu deiner Anmerkung: "Aber lösbar ist das Problem wie gesagt sicherlich" - nein, ist es nicht. Insgesamt haben wir hier wohl schon 500 Arbeitsstunden in das Problem gesteckt, und nein, es reicht nicht zum Bugreport. Einzige Fehler ist, das der Drucker dann nicht druckt, vollkommen unspezifisch. Den Rechner plattmachen und Neuinstallation löst das Problem - aber ich hatte immer gehofft, diese Zeiten wären vorbei.
Von ------------------------------ am Fr, 17. Februar 2012 um 23:07 #
> Es ist einfach so, das auch nach über 10 Arbeitsstunden der Drucker nicht funktioniert > Insgesamt haben wir hier wohl schon 500 Arbeitsstunden in das Problem gesteckt
a) wie geht das bitte zusammen? b) wenn als Lösungsansatz "Neuinstallation" auch nur in Betracht kommt, wundert es mich nicht wirklich. So was macht man schlicht nicht (außer, das System wurde kompromittiert) - auch nicht als Ubuntu Nutzer. Auch mit einer Fantastillionen "Arbeitsstunden" werdet ihr da nicht sehr weit kommen.
Offensichtlich unterscheidet sich die host Konfiguration von der des virtuellen clients, denn ein Defekt auf niedere Ebene (usb/udev) kann ja ausgeschlossen werden (da der host dann den client nicht weiterreichen könnte)
0. Trivial aber sehr beliebt: Drucker ist angehalten und muß einfach gestartet werden (localhost:631) 1. lokale Firewall kontrollieren, wenn das System nicht direkt am Netz hängt und eine hat -> abschalten, testen. (im Zweifel eben vom Internet trennen) 2. ähnliches gilt für alle Einträge in /etc/hotst* (je nachdem ob der Drucker direkt an einem Einzelplatzsystem oder einem Server angebunden ist) 3. loglevel in /etc/cups/cupsd.conf raufsetzen, cups daemon neu starten (nicht den Rechner ...) Druck testen und mal schauen, was /var/log/cups/* so her gibt (die ohne Ziffer am Ende sind die aktuellsten) - im Zweifel mit dem error_log auf Fragetour gehen. 4. Wenn's gar nicht geht: wireshark und den entsprechenden socket sniffen. 5. HP spezifisch: einige Drucker von denen benötigen ein Zertifikat, der installer muckt manchmal rum - vor allem wenn python auf die falsche Version (afaik 3 statt 2) linkt 6. Abseitig: ghostscript/fonts oder was auch immer nicht installiert o.ä. oder Pfade falsch gesetzt
Mehr fällt mir aus dem Stand nicht ein. Ich drucke nicht besonders viel (Blöde Baummörderei. Wenn das hier einer meiner Lohnsklaven liest: Ja. Das mit dem "feuern" meine ich ernst. Todernst.) aber hatte eigentlich nie irgendwelche Schwierigkeiten, die Dinger an den Start zu kriegen.
Und hört gefälligst mit dem "Neuinstallieren" auf. Es ist vieeeeeel Sinnvoller einmal zu kapieren wo's hakt als immer wieder die standardconfig auf's Neue zu zerschießen. Bitte.
Das ist eine gute Zusammenfassung des Vorgehens. Mache ich ähnlich, aber man muss erst mal darauf kommen, da es nichts o offensichtlich ist. Wäre einen Kurztipp wert.
Bevor ich mit Wireshark etwas diagnostiziere, wende ich aber erst mal strace an.
Danke erstmal, hier nur kurz die Antworten: 0: Nein, ist ok 1: Nein, ist ok 2:Nein, ist ok 3: Nichts 4: zu Zeitaufwendig 5: Nein 6: Nein
Das Neuinstallieren ist im Regelfall die ökonomischte Lösung, wir haben "vor Ort" max. 1 Arbeitstunde, um einen Drucker zu installieren, wenn ich wie letztens mal 10 Stunden investiere, dann nur, weil es mein privater Gentoo Rechner war. Wir haben früher versucht, da etwas zu finden, viel Arbeitszeit investiert, das können wir uns nicht mehr leisten. Eine Neuinstallation dauert nur ca. 10 Minuten Arbeitszeit, wird remote gemacht und ist damit äußerst effektiv und günstig. Wir benutzen und installieren seit über 15 jahren Linux und machen seitdem nichts mehr mit Windows, Ich liebe Linux geradezu und wir haben z.B. eine freie Warenwirtschaft für Linux programmiert ( bis jetzt über 270 Mannjahre Entwicklung, http://www.cuon.org). Trotzdem halte ich CUPS für eine PEST !!!! Und wenn du unter google "cups error" 29 millionen Einträge findest, dann weißt du auch warum. Wir kaufen und benutzen nur Drucker, die unter Linux problemlos laufen. Trotzdem ist es immer ein Abenteuer, einen Drucker zu installieren - und das sollte nicht sein. Und wo's hakt, wissen wir: CUPS
>Und wenn du unter google "cups error" 29 millionen Einträge findest, dann weißt du auch warum.
Ja, ich weiß warum. Du kannst nicht googeln. Nur damit du vielleicht auch drauf kommst zB "Windows error" 632 millionen Einträge, "solaris error" 105 millionen Einträge, ...
Von DriverDevel am Sa, 18. Februar 2012 um 14:16 #
Diese Aussagen hier kann ich nach zig Jahren mit zuvielen Problemen mit CUPS absolut, vollständig und 100%ig zumindest "gefühlsmässig" nachvollziehen.
Es gibt bei CUPS (zumindest auf Debian) - hin und wieder Font-Probleme - erstaunlich massive Probleme mit HP-LaserJets (das ist halt das, was hier so rumsteht) - Probleme mit (Nicht-)Duplex-Druck - misc.
Ich hatte z.B. einen Fall, wo sich mehrere verschiedene(!) HPs in der zentralen select/poll-Loop des printer backends von CUPS flachgelegt haben, mit dem Resultat 100% CPU-Auslastung des CUPS-Daemon (ergo natürlich: DoS). Das führte dann zu einer längeren Analyse, inkl. Installation der Debug-Packages, sogar manuellem Build des Backends mit versuchten Fixes, ausführlichem Bug-Report, ... (m.W. kurz danach aufgrund meines Berichts gefixt worden) Das härteste an der Sache war aber, dass ~ um diesen CUPS-Versionsstand herum sowohl der spezielle HP-seitige erweiterte CUPS-Support als auch die andere Konfiguration per Port 9100 (HP JetDirect?) beide _fatale_ Fehler hatten und somit _beides_ nicht wirklich ging, auf mehreren ziemlich unterschiedlichen LaserJets.
Fazit: CUPS "funktioniert", wenn es funktioniert. Aber es kann verdammt häufig eben "nicht funktionieren" (bei mir gab es in > 5 Jahren auf nur _einer_ - immer aktuell gehaltenen - Systemhistorie fast fünfmal Probleme).
Von der absoluten Usability-Katastrophe bei der Einrichtung eines (ja, ebenfalls ein weiterere _anderer_!) LaserJets unter RHEL5 nur soviel: - Modellnummer in RHEL5 Standard-GNOME-Setup nicht unterstützt (2100 irgendwas oder so) - openprinting.org behauptete: von RHEL5 unterstützt (NEIN, aktuellstes Package >> 3 Jahre URALT und damit 3 Monate zu alt, bei einem uralten HP-Drucker!!) - openprinting.org bot neueres .rpm an - Installation ging NICHT (IIRC Dependencies...) - Source-Build ging nicht wg. autoconf-Versions-Inkompatibilitäten (jaja, die berüchtigten Probleme...) - Fazit: der Rettungsanker wäre gewesen, das als sterbenslangweiligen "generischen" PostScript-Drucker einzurichten, ggf. unter Angabe von custom-.ppd's o.ä.) - ich hab das ganze Vorhaben dann genervt in die Ecke geschmissen... (nach dem Motto "wenn das schon sooo anfängt......") Und neulich mit einer neuen, ungetweakten CUPS-Installation auf MEPIS auch wieder HP-Probleme gehabt... (ewig nix gedruckt)
Von DeepThought am Sa, 18. Februar 2012 um 20:56 #
Versteh ich das richtig? Du hast ein System mit dem es läuft und ein System bei dem es nicht läuft. Prima, dann kannst du doch schon mal anfangen die Systemkonfiguration inkl. Versionen der verwendeten Packages, Netzwerkonfiguration, etc. vergleichen! Was steht den in Logfiles? Habt ihr euch den Weg des "Ausdrucks" durch das System inkl. Netzwerk angeschaut bzw. den Job einfach mal abgefangen? Wird es wirklich an den richtigen Printer geschickt? etc. etc. etc. Es gibt soviele Möglichkeiten, wo es beim Drucken hängen kann, es muss nicht unbedingt CUPS sein.
Vielleicht hat sich ja nur die IP des Druckers geändert. Manchmal ist DHCP einfach so fies, und vergibt einfach eine neue! Oder ihr habt Ubuntu im Einsatz und der Kunde klickt auf den "Upgrade"-Button im Notifier und: Nüscht geht mehr!
Wie gesagt es gibt zig Möglichkeiten ausser CUPS woran es hängen kann, das am Drucker kein Ausdruck herauskommt. Eure 500 versenkten Arbeitsstungen sprechen jedenfalls nicht gerade dafür, das ihr euch besonders gut mit der Systemadministration von Linux auskennt. Im Regelfall kann ich dir nach 10 Minuten sagen, wo es hängt, und dort eine genauere Analyse machen. ABER dazu muss man halt Wissen, welchen Weg der "Ausdruck" von der Applikation zum Drucker nimmt, und halt dann entsprechend abklopfen.
"Aber lösbar ist das Problem wie gesagt sicherlich" - nein, ist es nicht.
Doch ist es, sogar sehr wahrscheinlich. Wenn ich deine Posts richtig interpretiere, geht meine Vermutung sogar sehr stark dahin, das euer Problem in dem Fall nicht CUPS ist.
Hallo,
Es ist einfach so, das auch nach über 10 Arbeitsstunden der Drucker nicht funktioniert, da er aber von einer VB auf dem selben Rechner läuft, ist der Drucker ok und auch der Rechner ok.
Es ist aber so, das jedes Jahr ca. 10% der Druckerinstallationen mit CUPS zu unlösbaren Problems führen. Die einzige Möglichkeit ( ich will das nicht Lösung nennen) , die dann meistens funktioniert, ist, alle Daten zu sichern, den betreffenden Rechner komplett neu zu installieren und dann läuft der Drucker meistens. Das ist natürlich alles andere als schön, aber anscheinend unvermeidbar.
Zu deiner Anmerkung: "Aber lösbar ist das Problem wie gesagt sicherlich" - nein, ist es nicht. Insgesamt haben wir hier wohl schon 500 Arbeitsstunden in das Problem gesteckt, und nein, es reicht nicht zum Bugreport. Einzige Fehler ist, das der Drucker dann nicht druckt, vollkommen unspezifisch. Den Rechner plattmachen und Neuinstallation löst das Problem - aber ich hatte immer gehofft, diese Zeiten wären vorbei.
Tschüss
Jürgen
> Es ist einfach so, das auch nach über 10 Arbeitsstunden der Drucker nicht funktioniert
> Insgesamt haben wir hier wohl schon 500 Arbeitsstunden in das Problem gesteckt
a) wie geht das bitte zusammen?
b) wenn als Lösungsansatz "Neuinstallation" auch nur in Betracht kommt, wundert es mich nicht wirklich. So was macht man schlicht nicht (außer, das System wurde kompromittiert) - auch nicht als Ubuntu Nutzer. Auch mit einer Fantastillionen "Arbeitsstunden" werdet ihr da nicht sehr weit kommen.
Offensichtlich unterscheidet sich die host Konfiguration von der des virtuellen clients, denn ein Defekt auf niedere Ebene (usb/udev) kann ja ausgeschlossen werden (da der host dann den client nicht weiterreichen könnte)
0. Trivial aber sehr beliebt: Drucker ist angehalten und muß einfach gestartet werden (localhost:631)
1. lokale Firewall kontrollieren, wenn das System nicht direkt am Netz hängt und eine hat -> abschalten, testen. (im Zweifel eben vom Internet trennen)
2. ähnliches gilt für alle Einträge in /etc/hotst* (je nachdem ob der Drucker direkt an einem Einzelplatzsystem oder einem Server angebunden ist)
3. loglevel in /etc/cups/cupsd.conf raufsetzen, cups daemon neu starten (nicht den Rechner ...) Druck testen und mal schauen, was /var/log/cups/* so her gibt (die ohne Ziffer am Ende sind die aktuellsten) - im Zweifel mit dem error_log auf Fragetour gehen.
4. Wenn's gar nicht geht: wireshark und den entsprechenden socket sniffen.
5. HP spezifisch: einige Drucker von denen benötigen ein Zertifikat, der installer muckt manchmal rum - vor allem wenn python auf die falsche Version (afaik 3 statt 2) linkt
6. Abseitig: ghostscript/fonts oder was auch immer nicht installiert o.ä. oder Pfade falsch gesetzt
Mehr fällt mir aus dem Stand nicht ein. Ich drucke nicht besonders viel (Blöde Baummörderei. Wenn das hier einer meiner Lohnsklaven liest: Ja. Das mit dem "feuern" meine ich ernst. Todernst.) aber hatte eigentlich nie irgendwelche Schwierigkeiten, die Dinger an den Start zu kriegen.
Und hört gefälligst mit dem "Neuinstallieren" auf. Es ist vieeeeeel Sinnvoller einmal zu kapieren wo's hakt als immer wieder die standardconfig auf's Neue zu zerschießen. Bitte.
Das ist eine gute Zusammenfassung des Vorgehens. Mache ich ähnlich, aber man muss erst mal darauf kommen, da es nichts o offensichtlich ist. Wäre einen Kurztipp wert.
Bevor ich mit Wireshark etwas diagnostiziere, wende ich aber erst mal strace an.
Danke erstmal, hier nur kurz die Antworten:
0: Nein, ist ok
1: Nein, ist ok
2:Nein, ist ok
3: Nichts
4: zu Zeitaufwendig
5: Nein
6: Nein
Das Neuinstallieren ist im Regelfall die ökonomischte Lösung, wir haben "vor Ort" max. 1 Arbeitstunde, um einen Drucker zu installieren, wenn ich wie letztens mal 10 Stunden investiere, dann nur, weil es mein privater Gentoo Rechner war.
Wir haben früher versucht, da etwas zu finden, viel Arbeitszeit investiert, das können wir uns nicht mehr leisten.
Eine Neuinstallation dauert nur ca. 10 Minuten Arbeitszeit, wird remote gemacht und ist damit äußerst effektiv und günstig.
Wir benutzen und installieren seit über 15 jahren Linux und machen seitdem nichts mehr mit Windows, Ich liebe Linux geradezu und wir haben z.B. eine freie Warenwirtschaft für Linux programmiert ( bis jetzt über 270 Mannjahre Entwicklung, http://www.cuon.org).
Trotzdem halte ich CUPS für eine PEST !!!! Und wenn du unter google "cups error" 29 millionen Einträge findest, dann weißt du auch warum. Wir kaufen und benutzen nur Drucker, die unter Linux problemlos laufen.
Trotzdem ist es immer ein Abenteuer, einen Drucker zu installieren - und das sollte nicht sein.
Und wo's hakt, wissen wir: CUPS
Tschüss
Jürgen
>Und wenn du unter google "cups error" 29 millionen Einträge findest, dann weißt du auch warum.
Ja, ich weiß warum. Du kannst nicht googeln.
Nur damit du vielleicht auch drauf kommst zB "Windows error" 632 millionen Einträge, "solaris error" 105 millionen Einträge, ...
Ob Linux das richtige für euch ist?
gg lala
Diese Aussagen hier kann ich nach zig Jahren mit zuvielen Problemen mit CUPS absolut, vollständig und 100%ig zumindest "gefühlsmässig" nachvollziehen.
Es gibt bei CUPS (zumindest auf Debian)
- hin und wieder Font-Probleme
- erstaunlich massive Probleme mit HP-LaserJets (das ist halt das, was hier so rumsteht)
- Probleme mit (Nicht-)Duplex-Druck
- misc.
Ich hatte z.B. einen Fall, wo sich mehrere verschiedene(!) HPs in der zentralen select/poll-Loop des printer backends von CUPS flachgelegt haben, mit dem Resultat 100% CPU-Auslastung des CUPS-Daemon
(ergo natürlich: DoS).
Das führte dann zu einer längeren Analyse, inkl. Installation der Debug-Packages, sogar manuellem Build des Backends mit versuchten Fixes, ausführlichem Bug-Report, ... (m.W. kurz danach aufgrund meines Berichts gefixt worden)
Das härteste an der Sache war aber, dass ~ um diesen CUPS-Versionsstand herum sowohl der spezielle HP-seitige erweiterte CUPS-Support als auch die andere Konfiguration per Port 9100 (HP JetDirect?) beide _fatale_ Fehler hatten und somit _beides_ nicht wirklich ging, auf mehreren ziemlich unterschiedlichen LaserJets.
Fazit: CUPS "funktioniert", wenn es funktioniert.
Aber es kann verdammt häufig eben "nicht funktionieren" (bei mir gab es in > 5 Jahren auf nur _einer_ - immer aktuell gehaltenen - Systemhistorie fast fünfmal Probleme).
Von der absoluten Usability-Katastrophe bei der Einrichtung eines (ja, ebenfalls ein weiterere _anderer_!) LaserJets unter RHEL5 nur soviel:
- Modellnummer in RHEL5 Standard-GNOME-Setup nicht unterstützt (2100 irgendwas oder so)
- openprinting.org behauptete: von RHEL5 unterstützt (NEIN, aktuellstes Package >> 3 Jahre URALT und damit 3 Monate zu alt, bei einem uralten HP-Drucker!!)
- openprinting.org bot neueres .rpm an - Installation ging NICHT (IIRC Dependencies...)
- Source-Build ging nicht wg. autoconf-Versions-Inkompatibilitäten (jaja, die berüchtigten Probleme...)
- Fazit: der Rettungsanker wäre gewesen, das als sterbenslangweiligen "generischen" PostScript-Drucker einzurichten, ggf. unter Angabe von custom-.ppd's o.ä.) - ich hab das ganze Vorhaben dann genervt in die Ecke geschmissen... (nach dem Motto "wenn das schon sooo anfängt......")
Und neulich mit einer neuen, ungetweakten CUPS-Installation auf MEPIS auch wieder HP-Probleme gehabt... (ewig nix gedruckt)
Gesamtfazit: NICHT wirklich glücklich.
Versteh ich das richtig? Du hast ein System mit dem es läuft und ein System bei dem es nicht läuft. Prima, dann kannst du doch schon mal anfangen die Systemkonfiguration inkl. Versionen der verwendeten Packages, Netzwerkonfiguration, etc. vergleichen! Was steht den in Logfiles? Habt ihr euch den Weg des "Ausdrucks" durch das System inkl. Netzwerk angeschaut bzw. den Job einfach mal abgefangen? Wird es wirklich an den richtigen Printer geschickt? etc. etc. etc. Es gibt soviele Möglichkeiten, wo es beim Drucken hängen kann, es muss nicht unbedingt CUPS sein.
Vielleicht hat sich ja nur die IP des Druckers geändert. Manchmal ist DHCP einfach so fies, und vergibt einfach eine neue! Oder ihr habt Ubuntu im Einsatz und der Kunde klickt auf den "Upgrade"-Button im Notifier und: Nüscht geht mehr!
Wie gesagt es gibt zig Möglichkeiten ausser CUPS woran es hängen kann, das am Drucker kein Ausdruck herauskommt. Eure 500 versenkten Arbeitsstungen sprechen jedenfalls nicht gerade dafür, das ihr euch besonders gut mit der Systemadministration von Linux auskennt. Im Regelfall kann ich dir nach 10 Minuten sagen, wo es hängt, und dort eine genauere Analyse machen. ABER dazu muss man halt Wissen, welchen Weg der "Ausdruck" von der Applikation zum Drucker nimmt, und halt dann entsprechend abklopfen.
Doch ist es, sogar sehr wahrscheinlich. Wenn ich deine Posts richtig interpretiere, geht meine Vermutung sogar sehr stark dahin, das euer Problem in dem Fall nicht CUPS ist.