nachdem ich bislang nur am virtuellen Client getestet habe, bin ich gerade mal dazu gekommen einen echten Client zu testen. Alle Drucker sind am Server-Cups mit dem Präfix cupspykota: definiert, was unter Ubuntu 12.04 (angepasstes Mustercloop) perfekt funktioniert.
Folgendes Verhalten habe ich unter dem Mustercloop 16.04:
Testseite über Systemeinstellungen --> Drucker: Das Abfragefenster des Drucknotifiers erscheint, bei Bestätigung wird gedruckt. Also wie es sein soll.
Druckauftrag aus Libre Office, Firefox oder Dokumentenbetrachter (also aus beliebigen Anwendungen):
Es passiert offensichtlich nichts.
Der Blick in die Druckerwarteschlange offenbart, dass für den Druckauftrag bei Status erst “nicht angeschlossen?” und dann “Fehler” erscheint.
Der Druckauftrag landet dann in der Liste der abgeschlossenen Druckaufträge, ohne dass das Drucknotifier-Fenster erscheint und ohne dass gedruckt wird.
Was mich irritiert ist, dass die Testseite wie gesagt funktioniert, nur aus Anwendungen heraus geht’s nicht.
Edit
Wenn ich statt auf dem Standard-sw-Drucker einen Druckauftrag auf den Farblaser gebe, kommt das Fenster, allerdings im HIntergrund. Danach behauptet der Drucknotifier aber, das Guthaben sei null.
Alles sehr strange…
/Edit
Irgendwer hatte bei meinen früheren Anfragen berichtet, dass es bei ihm unter 16.04 problemlos funktioniert.
Nun stellt sich die Frage: Was läuft bei mir schief und wie kann ich das debuggen?
Druckquota sind bei uns ein zentraler Bestandteil und wir würden nur ungern darauf verzichten müssen.
ich habe jetzt nochmal im Wiki gesucht und die Seite zur Fehlerbehebung entdeckt.
Auf dem Server finde ich schon mal den Grund, warum beim Drucken aus einer Anwendung kein Abfragefenster kommt:
Die Abfrage wird -auch wenn ich nicht weiß, warum oder wie, „automatisch“ mit „cancel“ beantwortet.
Im Log auf dem Server finde ich nämlich:
Jul 4 10:20:03 afr-server PyKota: (PID 10718) : Command line arguments : „/usr/bin/pknotify“ „–destination“ „DuplexNoTumble:7654“ „–timeout“ „120“ „–confirm“ „Hallo auer.\nIhr Druckauftrag mit der ID 37051 für den Drucker laz-sw-Brother-HL5450 ist 1 Seiten lang\nund wird 0.05 Guthabeneinheiten kosten.\n\nDerzeit verfügen Sie über 39.34 Guthabeneinheiten.\n\nWollen Sie wirklich drucken?“
Jul 4 10:20:03 afr-server PyKota: (PID 10711) : auer@laz-sw-Brother-HL5450(37051) => User’s confirmation received : CANCEL
Warum da aber ein „User’s confirmation received : CANCEL“ am Server ankommt, ohne dass ein Fenster erscheint, bei dem man etwas hätte auswählen können, …
Edit
Noch kurioser ist aber, dass das beim Farblaser nicht passiert (bislang teste ich nur die Drucker in einem Raum).
/Edit
Edit 2
Nachdem man auf dem Farblaser gedruckt hat, wird einem gelb hinterlegt ein Guthaben von -0,2 angezeigt. Man kann auf dem Farblaser aber weiter drucken.
/Edit 2
Offensichtlich arbeitet unter Ubuntu 16.04 der Drucknotifier von Martin (zumindest bei mir) nicht wie er soll. Ich denke, da bräuchte ich nun wirklich dringend Hilfe beim weiteren debuggen, um das Problem zu finden und zu lösen.
Edit 3
Die URI am Server sind
Farblaser:
cupspykota:socket://10.16.61.254
sw-Laser:
cupspykota:lpd://10.16.61.253/P1
Eventuell bewirkt die Warteschlangenangabe lpd oder der Zusatz P1 das Verhalten?!? Allerdings unter ubuntu 12.04 geht’s wie gesagt problemlos.
/Edit 3
Ich konnte den sw-Laser auf cupspykota:socket://10.16.61.253 umstellen. Vom Server druckt der Drucker auch so. Das Verhalten bei Druckauftrag am Client ist aber gleich: Ohne dass das Abfragefenster erscheint, wird „Cancel“ als Antwort am Server empfangen.
Wer kann mir beim weiteren debuggen helfen? Ich bin jetzt mit meinem Latein glaube ich endgültig am Ende.
ich habe das heute nochmal getestet:
3 Drucker sind im Raum, in dem der Test-PC mit der 16.04-Installation steht. Druckauftrag an den Kyocera Farblaser sowie an den Ricoh Kopierer:
Das Abfragefenster kommt, alles wunderbar.
Druckauftrag an den Brother sw-Laser:
Das Abfragefenster kommt nicht, im Serverlog steht wie neulich schon geschrieben dann trotzdem “User’s confirmation received : CANCEL”.
Das ist doch mehr als kurios. Kann da wirklich niemand beim Debuggen helfen?
Hallo,
diesen Fehler mit canceled ohne dass ein Fenster erscheint hatte ich auch. Bei meinem System hat eine kleine Änderungen inder smb.conf geholfen, muss aber in der Schule nachschauen. Heute Mittag weiß ich mehr
Gruß Markus
Habs gefunden:
auf dem server in der smb.conf sollte im Abschnitt folgendes hinzugefügt bzw. angepasst werden:
JobPrivateAccess all
JobPrivateValues none
SubscriptionPrivateAccess all
SubscriptionPrivateValues none
dann sollte kein cancel mehr automatisch gesendet werden
Gruß
Markus
diesen Fehler mit canceled ohne dass ein Fenster erscheint hatte ich
auch. Bei meinem System hat eine kleine Änderungen inder smb.conf
geholfen, muss aber in der Schule nachschauen. Heute Mittag weiß ich mehr
wow, das klingt jetzt erstmalig nach einer richtig heißen Spur und nicht
meinem Gestocher im Nebel.
Wenn du die Änderung nachschaust und postest wäre das echt super
hilfreich. Ich danke dir schon im Voraus !!
da ich per E-Mail mitlese, habe ich erst spät gesehen, dass du deinen
Post editiert hast - da bekomme ich keine neue E-Mail wenn er schon
versendet wurde.
Habs gefunden:
auf dem server in der smb.conf sollte im Abschnitt folgendes
hinzugefügt bzw. angepasst werden:
Die Einträge gibt es bei mir noch nicht. Leider schreibst du nicht, in
welchem Abschnitt das hin soll.
Ich vermute mal unter [global] im Bereich *** Printing *** ?
kann es sein, das du gar nicht die smb.conf meinst sondern die cupsd.conf?
Da habe ich nämlich Einträge der Art JobPrivateAccess all
Ich habe deine Einträge also mal in die cupsd.conf am Server und ins
Postsync für den 16.04 Client geschrieben.
Allerdings scheint auch das nichts zu bewirken.
Auf dem sw-Laser bekomme ich nach wie vor kein Bestätigungsfenster,
sondern es wird gleich abgebrochen
Bei folgenden Druckern kommt das Fenster:
cupspykota:socket://10.16.61.254
cupspykota:lpd://10.16.61.252/lp
Ob der Drucker mit lpd oder socket konfiguriert ist scheint also egal,
und auch die Angabe einer Warteschlange nach der IP führt nicht
zwangsläufig zum Nichtfunktionieren.
