Firefox wartet auf cups-daemon

[c1ue]

EDIT: Titel und Inhalt des Themas geändert

Hallo,

Firefox wartet auf cups-daemon, wenn ich drucken will. Ich möchte aber gerne ohne cups-daemon auskommen. Fehlt dieser, so wartet Firefox erst 1,5 Minuten, bevor er mir den Druck-Dialog anzeigt. Das ist sehr nervig. Er druckt nämlich auch völlig ohne cups-daemon, nur eben nach dieser elenden Wartezeit.

Gibt es eine Möglichkeit, Firefox das warten auf den cups-daemon abzugewöhnen?

[guennid]

Ich weiß ja nicht viel, denke, aber dass gar nicht sein kann, was du da behauptest, ergo dir ein Denkfehler unterläuft. Ein Linux-System benötigt, wie jedes andere OS eine Druckserver-Software und da gibt es, was Linux betrifft, nur cups oder das nun ziemlich alte lpr(n)g. Ich kann mir nicht vorstellen, dass firefox da wie zu DOS-Zeiten eine eigene Lösung pflegt, ergo dass der browser überhaupt ohne die System-Druck-Software druckt. Aber wie gesagt, ich weiß nicht viel, aber dass hier überraschte mich.

Grüße, Günther

[willy4711]

Ich kann mir nicht vorstellen, dass firefox da wie zu DOS-Zeiten eine eigene Lösung pflegt, ergo dass der browser überhaupt ohne die System-Druck-Software druckt

Firefox hat schon seit langem einen eingebauten pdf-Viewer, mit dem man auch "Drucken" kann:
pdf.js --> https://github.com/mozilla/pdf.js
Das "Drucken" beschränkt sich meiner Meinung nach aber auf des Speichern. Was anderes ist mir im Druckdialog (Bildchen)
auch noch nicht untergekommen. Das ist dann deckungsgleich mit printer-driver-cups-pdf.

Um das auf Papier zu bringen braucht man dann halt was "materielles", samt Cups und der Einrichtung eines Druckers.
Wenn der (materielle) Drucker in Cups nicht eingerichtet ist, gibt es halt Probleme, da die wenigsten Programme
einen angeschlossenen Drucker selbständig finden könne. (da gab es ja vor kurzem einen Thread dazu)

[c1ue]

Ups, da hab ich wohl eine entscheidende Info weg-editiert:

Ich meinte natürlich drucken als PDF Datei

Und dafür brauchte Firefox noch nie den cups-daemon. Firefox tuts auch ohne den cups-daemon, nur halt nach einer gewaltig nervigen komplett-freeze-Zeit von ca. 1,5 Minuten, in denen er einfach "hängt".

[guennid]

Firefox hat schon seit langem einen eingebauten pdf-Viewer, mit dem man auch "Drucken" kann:
pdf.js --> https://github.com/mozilla/pdf.js
Das "Drucken" beschränkt sich meiner Meinung nach aber auf des Speichern. Was anderes ist mir im Druckdialog (Bildchen)
auch noch nicht untergekommen.

Ich meinte natürlich drucken als PDF Datei
Und dafür brauchte Firefox noch nie den cups-daemon.

Wozu auch? Das machen alle Programme, die ich kenne, die mit PDF umgehen können. Aber das ist kein Drucken, auch wenn deren Werbe-Fuzzis das so nennen. Man sollte sich meiner Meinung nach auch in diesem Bereich um eine etwas präzisere Ausdrucksweise bemühen: Das „Beschreiben" einer Datei ist nun mal kein Drucken. Genauso idiotisch finde ich es, schick vom „Drucker“ zu sprechen, wenn Drucker-Software gemeint ist.
Der Thread-Titel ist nach wie vor irreführend. Kein „Firefox wartet auf den CUPS-Dämon“ für das Beschreiben einer PDF-Datei.

die wenigsten Programme (können) einen angeschlossenen Drucker selbständig finden. (da gab es ja vor kurzem einen Thread dazu).

Wenn du denselben Thread meinst, an den ich denke, dann ging's da um reales Drucken und das scheiterte zunächst, wenn ich recht erinnere, eben genau am nicht vohandenen oder fehlkonfiguierten CUPS. Warum da der firefox so lange braucht bei dem Beschreiben eines PDFs, weiß ich auch nicht, aber mit Drucken hat's nix zu tun. Mein geeqie tut sich unter stretch selbst beim realen Drucken ähnlich schwer, das CUPS zu finden. Aber das liegt an geeqie nicht am CUPS.

Grüße, Günther

[c1ue]

Ok, also lasst es mich so formulieren:

Wenn ich in Firefox eine PDF Datei erstellen will, so wartet Firefox quälend lange auf eine Antwort vom cups-daemon, obwohl das total unnötig ist.

Was ich jetzt gerne wüßte: Gibt es eine Möglichkeit ihm dies Verhalten (meinetwegen als Startparameter auf der Kommonadozeile) auszutreiben?

Ich würde es einfach bevorzugen, wenn ich ohne cups-daemon auskommen könnte.

[guennid]

Wenn ich in Firefox eine PDF Datei erstellen will, so wartet Firefox quälend lange auf eine Antwort vom cups-daemon

Glaub ich nicht! Wie kommst du zu der Annahme, dass der auf den Cups-Server wartet?

Ich habe keinen Firefox, aber wenn ich Palemoon (firefox-fork) in einem Netz ohne Cups laufen lasse, dann beobachte ich Ähnliches wie du: es dauert ziemlich lange, bis er mir anbietet, in eine PDF-Datei zu "drucken". Aber ich kann nicht erkennen, dass er die vergangene Zeit damit verbracht hätte, auf Cups zu warten. Wiewohl ich zugebe, dass der gtk-Dialog genauso aussieht, wie der, in dem ich jetzt einen Cups-eingerichteten Drucker auswählen könnte.

Ich würde es einfach bevorzugen, wenn ich ohne cups-daemon auskommen könnte.

Abgesehen davon, dass du das aktuell ja kannst, nur halt nicht besonders fix : Vielleicht fehlt den Firefox-Jungs einfach so'n feature: "Export nach PDF".

Grüße, Günther

[willy4711]

Ich würde es einfach bevorzugen, wenn ich ohne cups-daemon auskommen könnte.

Oder: Ich würde es einfach bevorzugen, mit dem Kopf durch die Wand zu wollen.

Hab mal folgendes Experiment gemacht:
VM / Cinnamon / Buster:
Alles, was möglich war, ohne mir Cinnamon komplett zu deinstallieren gepurgt: Log: 40702

Es verbleibt:

Code: Alles auswählen

dpkg -l *cups* |grep ii
ii  cups-pk-helper        0.2.6-1+b1   amd64        PolicyKit helper to configure cups with fine-grained privileges
ii  libcups2:amd64        2.2.10-6     amd64        Common UNIX Printing System(tm) - Core library
ii  libcupsfilters1:amd64 1.21.6-5     amd64        OpenPrinting CUPS Filters - Shared library

In dieser VM ist auch kein weiterer Drucker installiert:


Firefox öffnet sofort den Druck - Dialog.

Die Frage wäre also eher: Was hast du installiert. Irgend was Minimales (vermute ich). Und jetzt wunderst du dich, das nur die Hälfte funktioniert.

[guennid]

Was hast du installiert. Irgend was Minimales (vermute ich).

Sowas macht ein WINDOWS-User ja auch nicht!

Ich halte es schon für ziemlichen Dummfug, das Anlegen einer PDF-Datei unter Drucken zu subsumieren. Sowas kann man dort zusätzlich anbieten, aber wenn er Recht hat, dass da tatsächlich auf den Druck-Server gewartet wird, (1 1/2 min = 90 s. hört sich das nach systemd an?) dann ist das schlicht Unsinn.

[willy4711]

Ich halte es schon für ziemlichen Dummfug, das Anlegen einer PDF-Datei unter Drucken zu subsumieren.

Da hast du Recht. Aber es ist ja erst mal egal wie man das Kind nennt. Es geht darum, eine Webseite als PDF- Datei zu verewigen.

aber wenn er Recht hat, dass da tatsächlich auf den Druck-Server gewartet wird, (1 1/2 min = 90 s. hört sich das nach systemd an?) dann ist das schlicht Unsinn.

Das Stimmt eben nicht, wie ich oben (meine ich) nachgewiesen habe.
In der von mir dargestellten Installation gibt es einen Druck-Server nicht mehr.

[guennid]

In der von mir dargestellten Installation gibt es einen Druck-Server nicht mehr.

Was ja nicht heißt, dass da irgendwas 90s braucht, um das „einzusehen“. Du hattest buster. Was der TE hat, hat er nicht gesagt. Ich habe stretch (eher minimal ) und die gefühlte „Ewigkeit“ kann ich bestätigen.

[willy4711]

Was ja nicht heißt, dass da irgendwas 90s braucht, um das „einzusehen“

dann würde mich interessieren was bei dir

Code: Alles auswählen

dpkg -l *cups*

ergibt.
Letztendlich ist Firefox (oder auch irgend ein andere Browser) kein unabhängiges Ökosystem, sondern bedient sich der vom Betriebssystem zur Verfügung gestellten Ressourcen. Unter Windows sind das in diesem Fall irgendwelche Adobe - Sachen, unter Linux halt die rudimentären Ressourcen von CUPS (s.O)
und eventuell noch libgs9. Aber so genau weiß ich das natürlich auch nicht.

Wenn man es unbedingt minimal will, muss man halt testen. Ein Standard- System kann das halt "Out of the Box". , weil die "Päckchen Packer"
netterweise an so was gedacht haben.

[TomL]

Also nicht überall, wo 90 Sekunden draufsteht, ist automatisch systemd drin. Und an dieser Stelle hat systemd meiner Meinung nach auch wieder gar nix mit dem Problem zu tun. systemd ist ein Init-System und kümmert sich ganz sicher nicht um das Erstellen von pdf-Dokumenten.

Das Problem liegt meiner Meinung nach im Ghostscript-Prozessor, der nach meinem Kenntnisstand für das Erstellen von pdf-Dokumenten zuständig ist. Und Firefox enthält meines Wissen keinen eigenen embedded Ghostscript-Prozessor... aber das will ich nicht abschließend behaupten ... vielleicht war ja früher mal ein entsprechendes AddOn installiert, was dann gefühlsmäßig so ausgesehen hat, als könnte FF das selber. Was aber Fakt ist und auch nachzulesen (*) ist, cups setzt primär auf diesen Ghostscript-Prozessor und das ist vermutlich auch der Grund, warum das so häufig im Zusammenhang mit "Drucken als PDF" genannt wird. Wenn also eine Anwendung keinen eigenen (allerdings Lizenzgebundenen) Ghostscript-Interpreter enthält, kann sie imho nur den Umweg über Cups gehen.... was wiederum beinhaltet, dass Cups-Core-Elemente eben installiert sein müssen. Um darüber dann genau dazu zu kommen, was Willy sagt "...bedient sich der vom Betriebssystem zur Verfügung gestellten Ressourcen"

(*) http://www.openprinting.org/download/kp ... -PPDs.html

[guennid]

Und Firefox enthält meines Wissen keinen eigenen embedded Ghostscript-Prozessor...

Davon ging ich ja ebenfalls aus (s.o.) Aber dass dann das Erstellen eines PDFs zwangsläufig cups erfordert, hätte ich nicht gedacht. Glaub' ich auch jetzt noch nicht. In meinem oben beschriebenen Versuchszenario ist kein ghostscript und von cups lediglich libcups2 installiert

Code: Alles auswählen

dpkg -l | grep cups

und „Drucken in PDF“ wird von palemoon angeboten - nach Wartezeit. Funktioniert also prinzipiell.

Also nicht überall, wo 90 Sekunden draufsteht, ist automatisch systemd drin.

Ich hatt's auch nicht behauptet.

systemd ist ein Init-System und kümmert sich ganz sicher nicht um das Erstellen von pdf-Dokumenten.

Aber ums Starten und Stoppen von Diensten. Das war der Ausgangspunkt der Überlegung.

Grüße, Günther

[willy4711]

ist libgs9 bei dir installiert ?

Code: Alles auswählen

$ apt-cache depends libgs9
libgs9
  Hängt ab von: libgs9-common
  Hängt ab von: poppler-data
  Hängt ab von: libc6
  Hängt ab von: libcups2
  Hängt ab von: libcupsimage2
  Hängt ab von: libexpat1
  Hängt ab von: libfontconfig1
  Hängt ab von: libfreetype6
  Hängt ab von: libidn11
  Hängt ab von: libijs-0.35
  Hängt ab von: libjbig2dec0
  Hängt ab von: libjpeg62-turbo
  Hängt ab von: liblcms2-2
  Hängt ab von: libopenjp2-7
  Hängt ab von: libpaper1
  Hängt ab von: libpng16-16
  Hängt ab von: libtiff5
  Hängt ab von: zlib1g

GPL Ghostscript wird für Druck und Druckvorschau von PostScript/PDF genutzt. Es kann PostScript- und PDF-Dokumente in einer X11-Umgebung anzeigen. In der Regel arbeitet es als Backend für ein Programm wie ghostview.
Dieses Paket enthält die Ghostscript-Bibliothek, die die Möglichkeiten von GPL Ghostsript für Anwendungen verfügbar macht.

[guennid]

istDebian libgs9 bei dir installiert?

Nein.

[TomL]

(s.o.) Aber dass dann das Erstellen eines PDFs zwangsläufig cups erfordert, hätte ich nicht gedacht. Glaub' ich auch jetzt noch nicht.

Richtig, nicht cups ist zwingend erforderlich, sondern der Ghostscript-Interpreter.... nur in Cups ist genau der ein elementarer Bestandteil. Und mal ehrlich, welcher Programmierer plagt sich völlig unnötig mit einer eigenen Implementierung ab, wennn er es aufwandsneutral über Cups kriegen kann? Vielleicht gibts das, bestimmt sogar... ich als Entwickler würde das jedenfalls nicht tun. Und als Entscheider für ein großes Projekt auch nicht.

ist libgs9 bei dir installiert ?

Bei mir isses installiert.... und wirklich alles im Zusammenhang mit PDF funktioniert.. rauf wie runter, rechts wie links, krum wie gerade...

[guennid]

Und mal ehrlich, welcher Programmierer plagt sich völlig unnötig mit einer eigenen Implmentierung ab, wennn er es aufwandsneutral [...] kriegen kann?

Das ist ein Pappkamerad, Thomas. Darüber müssen zumindest wir beide hier nicht diskutieren.

Die Auslassung ist völlig bewusst vorgenommen, weil für mich nach wie vor offen ist, woher firefox/palemoon die nötige(?) „Implementierung“ bekommt.

Ich habe es nochmal so arrangiert, dass der Testrechner in einem Netz mit erreichbarem cupsd hängt. Ergebnis: Der fragliche Dialog erscheint sofort, ohne Verzögrung - und macht nach Auswahl von „PDF-Datei drucken“ haargenau dasselbe, was er - verzögert - auch im anderen Netz ohne cups macht. Ich neige immer mehr dazu, dem TE Recht zu geben, dass ein fehlendes CUPS völlig unnötigerweise für die Verzögerung verantwortlich ist.

Grüße, Günther

[willy4711]

Hab mal folgendes Experiment gemacht:
VM / Cinnamon / Buster:
Alles, was möglich war, ohne mir Cinnamon komplett zu deinstallieren gepurgt: Log: 40702

Es verbleibt:

Code: Alles auswählen

dpkg -l *cups* |grep ii
ii  cups-pk-helper        0.2.6-1+b1   amd64        PolicyKit helper to configure cups with fine-grained privileges
ii  libcups2:amd64        2.2.10-6     amd64        Common UNIX Printing System(tm) - Core library
ii  libcupsfilters1:amd64 1.21.6-5     amd64        OpenPrinting CUPS Filters - Shared library

Firefox öffnet sofort den Druck - Dialog.

Ergänzung: und libgs9

@ guennid: Bitte nochmal lesen, oder, falls zu anstrengend hier:

Code: Alles auswählen

Aptitude 0.8.11: log report
Thu, May  2 2019 21:16:50 +0200

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 0 packages, and remove 20 packages.
22.2 MB of disk space will be freed
========================================
[REMOVE, NOT USED] bc:amd64 1.07.1-2+b1
[REMOVE, NOT USED] cups-browsed:amd64 1.21.6-5
[REMOVE, NOT USED] cups-client:amd64 2.2.10-6
[REMOVE, NOT USED] cups-core-drivers:amd64 2.2.10-6
[REMOVE, NOT USED] cups-daemon:amd64 2.2.10-6
[REMOVE, NOT USED] cups-filters:amd64 1.21.6-5
[REMOVE, NOT USED] cups-filters-core-drivers:amd64 1.21.6-5
[REMOVE, NOT USED] cups-ipp-utils:amd64 2.2.10-6
[REMOVE, NOT USED] cups-ppdc:amd64 2.2.10-6
[REMOVE, NOT USED] cups-server-common:amd64 2.2.10-6
[REMOVE, NOT USED] libfontembed1:amd64 1.21.6-5
[REMOVE, NOT USED] libgutenprint-common:amd64 5.3.1-7
[REMOVE, NOT USED] libgutenprint9:amd64 5.3.1-7
[REMOVE, NOT USED] liblouisutdml-bin:amd64 2.7.0-5+b1
[REMOVE, NOT USED] liblouisutdml-data:amd64 2.7.0-5
[REMOVE, NOT USED] liblouisutdml8:amd64 2.7.0-5+b1
[REMOVE, NOT USED] libqpdf21:amd64 8.4.0-2
[REMOVE, NOT USED] printer-driver-gutenprint:amd64 5.3.1-7
[REMOVE, NOT USED] ssl-cert:amd64 1.0.39
[REMOVE (PURGE)] cups:amd64 2.2.10-6
========================================

Log complete.

===============================================================================

Aptitude 0.8.11: log report
Thu, May  2 2019 21:19:44 +0200

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 0 packages, and remove 7 packages.
========================================
[REMOVE (PURGE)] bc:amd64 (no version found)
[REMOVE (PURGE)] cups-browsed:amd64 (no version found)
[REMOVE (PURGE)] cups-core-drivers:amd64 (no version found)
[REMOVE (PURGE)] cups-daemon:amd64 (no version found)
[REMOVE (PURGE)] cups-filters:amd64 (no version found)
[REMOVE (PURGE)] printer-driver-gutenprint:amd64 (no version found)
[REMOVE (PURGE)] ssl-cert:amd64 (no version found)
========================================

Log complete.

=========================================================

[TomL]

Ich habe es nochmal so arrangiert, dass der Testrechner in einem Netz mit erreichbarem cupsd hängt. Ergebnis: Der fragliche Dialog erscheint sofort, ohne Verzögrung - und macht nach Auswahl von „PDF-Datei drucken“ haargenau dasselbe, was er - verzögert - auch im anderen Netz ohne cups macht. Ich neige immer mehr dazu, dem TE Recht zu geben, dass ein fehlendes CUPS völlig unnötigerweise für die Verzögerung verantwortlich ist.

Das hängt u.a. auch mit der GTK- bzw. QT-Implementierung zusammen, wie die das Druckmenü handhaben und in Folge mit dem Problem umgehen, wenn cups nicht installiert ist. LibreOffice mit QT-Dialoge kommt offensichtlich gut damit klar, Firefox mit GTK anscheinend weniger gut. Das hängt weitergehend also auch mit dem Umstand "driverless printing" zusammen, was systemisch als Fallback anscheinend irgendwie gelöst ist. Ich denke, wenn cups nicht installiert ist, wird beim PDF-Druck durch GTK verzögert irgendwann einfach auf ein solches Fallback-Szenario und weitergehend auf ein common-modul zurückgegriffen, welches eine PDL (Page Description Language) unterstützt, was im Regelfall dann automatisch wieder auf PDF hinausläuft.

Ich empfinde es zusammenfassend jedenfalls als müßig, sich mit einem Druck-Problem befassen, wenn jemand kein Cups installieren will. Ganz ehrlich, würde einer meiner User mit diesem Problem kommen, würde ich ihm 'nen Block und nen Bleistift geben und das Problem als erledigt abhaken. ... ... kommt mir ein wenig so vor, wie der Anspruch "Nein, ich will keine fossilen Brennstoffe, ich will das mein Wagen ohne fährt, hat er früher bergrunter ja auch getan. Und was bergrunter funktioniert, muss auch bergrauf klappen"

[guennid]

Die Installation von libcupsfilter1 hat hinsichtlich der Verzögerung nichts gebracht, cups-pk-helper installier' ich nicht, weil das Pakete nach sich zieht, die ich nicht haben will. Ich erinnere daran, dass ich in meinem „normalen“ Netz ein vollwertiges cups installiert habe und es mir insofern egal ist, wie der Browser via Druckdialog eine PDF-Datei aus einer Webseite macht. Aber für den TE könnte deine 1. Liste interessant sein.

Grüße, Günther

[c1ue]

Hier noch die gefragten Infos zu meinem System:

Debian Stable (Version 9) mit KDE

Noch zu der Frage, welches Paket nötig ist, um keine Verzögerung zu haben: cups-daemon.
Deinstalliert man das, und meldet sich ab und wieder an, dann dauerts sehr lange, wie von mir beschrieben.

@guennid
Es freut mich, dass Du mein Problem bestätigen konntest.

@TomL
Ich will halt ein schlankes System haben. Cups-daemon ist ja nachweislich auch total überflüssig, wenn ich eine PDF im Firefox erstellen will. Nur halt mit extrem nerviger Wartezeit.
Deinstallier doch mal bei dir cups-daemon und log Dich aus und wieder ein. Bin mal gespannt, was passiert, wenn Du dann den Drucken-Dialog in Firefox aufrufen willst.

@Alle
Sofern sich dieses Verhalten bestätigen sollte, ist es dann nicht als bug zu werten, da FF ja auch ohne cups-daemon ein PDF erzeugt ?

[willy4711]

@TomL
Ich will halt ein schlankes System haben. Cups-daemon ist ja nachweislich auch total überflüssig, wenn ich eine PDF im Firefox erstellen will. Nur halt mit extrem nerviger Wartezeit.
Deinstallier doch mal bei dir cups-daemon und log Dich aus und wieder ein. Bin mal gespannt, was passiert, wenn Du dann den Drucken-Dialog in Firefox aufrufen willst.

Liest du eigentlich, was ich geschrieben habe ? Aber wenn man mal von seiner Meinung überzeugt ist, sind Scheuklappen sehr hilfreich.

Hab jetzt keine Lust mehr zu diesem Thread

[guennid]

Sofern sich dieses Verhalten bestätigen sollte, ist es dann nicht als bug zu werten, da FF ja auch ohne cups-daemon ein PDF erzeugt ?

Als bug wohl nicht, aber dass das besonders sinnvoll gestaltet ist, finde ich auch nicht. Wiewohl man bedenken sollte: Cups ist ein Client-Server-System und je nachdem wie eingestellt, kann das dauern bis der Server bzw. die von willy genannten Pakete sich melden. Die Zeit muss abgewartet werden. Aber wenn man ihn/sie gar nicht braucht.

[c1ue]

Liest du eigentlich, was ich geschrieben habe ? Aber wenn man mal von seiner Meinung überzeugt ist, sind Scheuklappen sehr hilfreich.

Hab jetzt keine Lust mehr zu diesem Thread

Oh, sorry, da waren zu viele Antworten seit meinem letzten Besuch, da ist Deine etwas untergegangen. Sorry!

Falls Du doch noch Lust haben solltest, könntest Du mir eventuell noch mitteilen, ob Du nach der Deinstallation des Paketes cups-daemon dich mal ab und wieder angemeldet hast?

Bei mir reicht es nämlich schon, das Paket zu deinstallieren und dann Firefox neu zu starten, um dieses Verhalten beobachten zu können.

Ich habe aber echt keine Ahnung, ob eine VM gleichwertige Aussagen wie bei bare-metal-Installationen erlaubt.