Hallo,
ich habe es auch schon im Netrunner Forum geposted, es betrifft aber wohl auch mein aktuelles siduction mit kf5.
Auf meinem NAS habe ich Debian Jessie laufen mit eingerichteten Druckern. Meine Frau greift über ihren Dektop Rechner auf die NAS Drucker zu und ich über meinen.
Auf dem PC meiner Frau läuft Netrunner 16 mit kf5, auf meinem Debian Jessie, Netrunner 16 und siduction.
Bei allen Rechnern ist cups-browsed aktiv und zeigt mir auch jeweils die Remote Drucker.
Drucke ich von meinem PC aus zum Beispiel eine Mail aus claws-mail, kommt der Druckauftrag an und wird abgearbeitet. Starte ich dann den PC meiner Frau mit Netrunner 16, dabei bleibt mein Rechner an, und drucke aus claws-mail, zeigt der Druckdialog für kurze Zeit an "Connecting to printer" und dann "Printer is not responding".
Ein systemctl restart cups auf dem PC meiner Frau aktiviert dann den Remote Ausdruck.
Umgekehrt geht das auch: Starte ich zunächst den PC meiner Frau und schicke aus einer Applikation unter X einen Druckauftrag, wird der ordentlich vom Remote Drucker abgearbeitet. Starte ich dann meinen PC dazu und möchte etwa aus Iceweasel drucken, kommt wieder "Connecting to prrinter" und dann "Printer is not responding". Das passiert sowohl bei siduction als auch bei Netrunner 16. Auch dann werden die blockierten Druckaufträge erst durch systemctl restart cups auf meinem PC abgearbeitet.
Und jetzt das Komische: Starte ich beide PCs und logge mich nicht in kf5 oder icewm ein und drucke über den bash Prompt, zum Beispiel ls -la|lp -d lp0 dann kann ich beliebig viele Druckjobs abwechselnd von beiden PCs abschicken und die werden sofort abgearbeitet.
Weiß hier jemand Rat? Dieser Fehler ist schon ziemlich ätzend.
Viele Grüße,
Holger
Hatte auch mal ein cups Problem im Netzwerk, lag an cups-browsed und Namensauflösung.
Hatte damals aber gar keinen Zugriff über das Netz. Vielleicht hab ich aber auch nicht probiert cups einfach neu zu starten. Les mal folgendes dazu.
http://forum.siduction.org/index.php?topic=3830.0 (http://forum.siduction.org/index.php?topic=3830.0)
Hab aber Keine Ahnung ob das die Ursache ist. Ganz am Schluß von Seite 2 ist noch ein Link für die avahi konfiguration ins ubuntuuser forum.
werde interessiert weiterverfolgen ob eine Erklärung für das Phänomen gefunden wird.
Insbesondere würde mich interessieren, ob ein eintrag von :
BrowsePoll IP-Nr-des-NAS:631
in der cups-browsed.conf der Clients etwas an dem Verhalten ändert.
Hallo dieres,
danke für Deine Antwort. Leider bewirkt der Eintrag des NAS in die cups-browsed.conf keine Verbesserung.
Ich versuche mal, cups bei den Netrunner Systemen von Version 2.0.2 auf 1.7.5 zu bringen.
Viele Grüße,
Holger
Hallo,
ich habe gerade nochmals getestet, hier die wichtigsten Punkte:
NAS mit Jessie als Printserver
Verschiedene Clients mit Debian, siduction und Netrunner16, die per cups-browsed den Remote Drucker erkennen
Sind verschiedene Clients online und sind die grafischen Oberflächen gestartet, blockiert ein Client, nachdem von ihm erfolgreich ein Druckjob gestartet wurde, die anderen Clients beim Remote Drucken
Sind verschiedene Clients online ohne geladene grafische Oberflächen, und erfolgen die Druckaufträge über den Bash Prompt, gibt es keinerlei Blockierung und ich kann von verschiedenen Clients in rascher Folge Druckjobs starten, die auch sofort ausgeführt werden.
Nachtrag: Es liegt an cups 2.0.2.
Habe ich nur Clients mit cups 1.7.5 geladen, wie Debian, siduction oder Manjaro, bei welchem ich kürzlich cups von Version 2.0.2 auf 1.7.5 deaktualisiert habe, klappt der Ausdruck auch unter X-Applikationen von den verschiedenen Systemen ohne Schwierigkeiten.
Sobald ein Client mit cups 2.0.2 dazwischen hängt, kommt es zu den oben geschilderten Schwierigkeiten. Ich werde daher versuchen, Netrunner16 auf cups 1.7.5 zu deaktualisieren. Hoffentlich klappt das.
Viele Grüße,
Holger