CUPS: CUPSD und CUPS inaktiv

Deutsch (German) Anwendungen
#1

Hallo zusammen,
ich habe hier Opensuse 13.1 und Cups 1.5.4 aus den Opensuse-Repos. Daran hängt am USB ein HP Photosmart und übers LAN ein Brother HL3070.

Bis letzte Woche hat alles funktioniert. Anscheinend nach einem Update (es war letztens mal ein Cups-Update dabei) ist nach dem Hochfahren des Rechners zwar Cups und Cupsd “enabled” aber “Inactive”. Des halb kann ich die Drucker weder über localhost:631 noch über z.B. Plaspool ansprechen.

Also rufe ich Yast-System-Diensteverwaltung auf, schalte cups und cupsd ein und alles funktioniert wieder.

Was läuft hier schief? Wo muss ich ein “Häkchen” dransetzen, damit die Dienste wieder automatisch aktiviert werden? Ich dachte eigentlich die Diesnsteverawaltung tut das, aber das hilft nur jeweils nach dem Hochfahren.

Gruss

Jürgen

#2

Poste als root in separaten Code-Tags:

systemctl status cups.service

systemctl stop cups

systemctl disable cups.service

systemctl enable cups.service

systemctl start cups.service

Danach einmal neustarten und die Ausgabe von:

systemctl status cups.service
#3

Außerdem solltest du cups.socket disablen:

systemctl disable cups.socket

Per default wird cupsd nämlich gar nicht beim Booten gestartet, sondern systemd lauscht auf dem socket und startet cups wenn eine Anfrage kommt.
Das Update hat cups.socket dahingehend geändert, dass es (aus “Sicherheitsgründen”) nur mehr am lokalen Rechner auf Anfragen lauscht.

Cups selber kann aber gar nicht im Netzwerk lauschen wenn cups.socket aktiv ist.

Wenn jetzt cups.socket disabled ist und cups.service enabled, dann wird cups ganz normal beim Booten gestartet, lauscht im Netzwerk (falls konfiguriert) und alles sollte wie gewünscht funktionieren.

Eine andere Möglichkeit wäre cups.socket entsprechend zu ändern.
Dazu /usr/lib/systemd/system/cups.socket nach /etc/systemd/system kopieren und dort editieren.

Sh. dazu auch folgende Bugreports:
https://bugzilla.novell.com/show_bug.cgi?id=857372 (der ursprüngliche, der uns dieses Update bescherte)
https://bugzilla.novell.com/show_bug.cgi?id=860331
https://bugzilla.novell.com/show_bug.cgi?id=860481

#4

Außerdem solltest du cups.socket disablen:

Das wird aber auch mit dem Befehl ausgeführt:

systemctl disable cups.service 
rm '/etc/systemd/system/sockets.target.wants/cups.socket'
rm '/etc/systemd/system/printer.target.wants/cups.service'
rm '/etc/systemd/system/multi-user.target.wants/cups.path'
rm '/etc/systemd/system/cupsd.service'

Ein neuer wird mit dem Befehl angelegt:

systemctl enable cups.service 
ln -s '/usr/lib/systemd/system/cups.service' '/etc/systemd/system/cupsd.service'
ln -s '/usr/lib/systemd/system/cups.service' '/etc/systemd/system/printer.target.wants/cups.service'
ln -s '/usr/lib/systemd/system/cups.socket' '/etc/systemd/system/sockets.target.wants/cups.socket'
ln -s '/usr/lib/systemd/system/cups.path' '/etc/systemd/system/multi-user.target.wants/cups.path'
#5

Hallo Wolfi, hier erst mal die Outputs der einzelnen Befehle:

#6

Hallo Wolfi,
hier das Ergebnis nach Hochfahren (leider nicht wie erwartet/gewünscht):

systemctl status cups.service
cups.service - CUPS Printing Service
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)
   Active: inactive (dead)

nach einem systemctl start cups.service war wieder alles ok. Danach kommt folgender Status:

systemctl status cups.service
cups.service - CUPS Printing Service
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)
   Active: active (running) since So 2014-01-26 11:54:20 CET; 1min 1s ago
 Main PID: 3543 (cupsd)
   CGroup: /system.slice/cups.service
           └─3543 /usr/sbin/cupsd -f

Jan 26 11:54:20 linux-6o8d systemd[1]: Started CUPS Printing Service.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No limit for Validate-Job defined in policy allowallforanybody and no suitable template found.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No limit for Cancel-Jobs defined in policy allowallforanybody and no suitable template found.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No limit for Cancel-My-Jobs defined in policy allowallforanybody and no suitable template found.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No limit for Close-Job defined in policy allowallforanybody and no suitable template found.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No limit for CUPS-Get-Document defined in policy allowallforanybody and no suitable template found.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No JobPrivateAccess defined in policy allowallforanybody - using defaults.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No JobPrivateValues defined in policy allowallforanybody - using defaults.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No SubscriptionPrivateAccess defined in policy allowallforanybody - using defaults.
Jan 26 11:54:20 linux-6o8d cupsd[3543]: No SubscriptionPrivateValues defined in policy allowallforanybody - using defaults.

Gruss

Jürgen

#7

Update:

Ich habe nun sowohl wie in

https://bugzilla.novell.com/show_bug.cgi?id=860481

beschrieben die cups.socket geändert als auch das Update von Cups rückgeängig gemacht und cups-1.5.4-12.1.3 wieder installiert. Ergebnis: es funktioniert nicht mehr!! Erst händisches Anschalten von Cups oder das Anschalten meines USB-Druckers (der normalerweise abgeschalten ist) hilft.

Das ist alles sehr verwirrend! Wurde beim systemd auch was geändert oder wieso sieht er den Netzwerkdrucker nicht mehr? Wieso macht man solche Updates???

Gruss

Jürgen

#8

Nein, es wurde nur cups.socket geändert.

Aber du hast das was ich geschrieben habe falsch gelesen.
Du solltest cups.socket disablen, nicht cups.service.
Also:

sudo systemctl disable cups.socket

Wieso macht man solche Updates???

Weil man der Meinung war, dass es ein Sicherheitsrisiko ist, wenn cups.socket per default auf allen Netzwerkinterfaces lauscht.
Über die Konsequenzen auf bestehenden Default-Installationen (und die Verwirrung/Probleme für normale Benutzer) wurde anscheinend nicht nachgedacht…

#9

Hi Wolfi,
in meiner derzeitigen Konfiguration habe ich natürlich cups.service enabled und cups.socket disabled. Ist aber wie ich schon geschrieben habe ohne positive Wirkung gewesen.

Status derzeit: nach dem Hochfahren entweder USB-Drucker anschalten oder cups von Hand starten.

Gruss

Jürgen

#10

Hm, und vor dem Update ists gegangen? Wie gesagt, die einzige Änderung im Update war in /usr/lib/systemd/system/cups.socket.
Wenn cups.socket disabled ist, sollte das also absolut keine Auswirkung haben.
Hattest du cups.socket vorher schon disabled? Wenn nicht, hats vielleicht gerade deswegen funktioniert…

Was sagt “systemctl status cups.service” direkt nach dem Boot, also wenn es nicht geht? Wenn mans als root ausführt bekommt man etwas ausführlichere Meldungen aus dem Log.

Evtl. wird die Netzwerkverbindung zu spät aufgebaut?
Wie hängst du denn im Netzwerk? (über Kabel oder WLAN?)
Wenn’s eine WLAN-Verbindung über NetworkManager ist, solltest du vielleicht probieren, sie als “Systemverbindung” zu konfigurieren, damit sie schon beim Booten aufgebaut wird. (eine Benutzerverbindung wird erst beim Einloggen aufgebaut)

#11

Hallo Wolfi,
folgende Meldung als su:
systemctl status cups.service
cups.service - CUPS Printing Service
Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)
Active: inactive (dead)

Ich hänge über LAN am Netz und mache ifup… Daran hat sich nix geändert. Der Drucker hängt auch schon 1.5 Jahre über WLAN dran.
Bzgl. Zeitpunkt bin ich mir nicht 100% sicher, aber in etwa seit der Zeit des Cups-Updates (müsste letzte Woche gewesen sein, kommt nach Start von KDE vom Plasmoid Plaspool die Fehlermeldung “Verbindung fehlgeschlagen”.

So gings dann los: ich hab die Diensteeinstellung überprüft und festgestellt, dass Cups zwar enabled aber inaktiv ist.

im Cups-Log stehen nur meldungen NACH dem händischen aktivieren drin.

Wo kann ich noch nachschauen,um das ganz zu lösen? Oder könnte ich

systemctl start cups.service

vor dem KDE start in irgendein Skript reinpacken und starten?

Gruss

Jürgen

#12

Sagt leider auch nicht mehr.

Vielleicht hilfts ja, wenn du das cups.socket file von vor dem Update nimmst und cups.socket wieder enablest? Dann lauscht nämlich wie gesagt systemd auf Anfragen und startet dann cups bei Bedarf.

Also die Datei /etc/systemd/system/cups.socket editieren, mit “kdesu kwrite /etc/systemd/system/cups.socket” z.B., und folgendes hineinschreiben:

[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=631
ListenDatagram=0.0.0.0:631
BindIPv6Only=ipv6-only

[Install]
WantedBy=sockets.target

Dann rufe “sudo systemctl enable cups.socket” auf und alles sollte so sein wie vor dem Update.

Wenns dann immer noch nicht geht, kanns eigentlich nicht am cups update liegen.

#13

Hallo Wolfi,
also: bei meinem Laptop hats mit Änderung der cups.socket funktioniert. Bei meinem PC siehts nicht so gut aus. Nach wie vor das gleiche: Händisches Anmelden.

Ich hab jetzt mal nach dem Status von cups.socket geschaut (wenns nicht funktioniert):


systemctl status cups.socket
cups.socket - CUPS Printing Service Sockets
   Loaded: loaded (/etc/systemd/system/cups.socket; disabled)
   Active: inactive (dead)
   Listen: /var/run/cups/cups.sock (Stream)
           ::]:631 (Stream)
           0.0.0.0:631 (Datagram)

Es wird also weder cups.service noch cups.socket getartet!?

Gruss

Jürgen

#14

Tja, cups.socket ist “disabled”, also deaktiviert.
Rufe folgendes auf und es sollte gestartet werden: (hab ich das nicht schon mal erwähnt? :wink: )

sudo systemctl enable cups.socket

Allgemein muss ich sagen, deine Situation scheint mir folgendermaßen auszuschauen:
Das Update hat eigtl. nichts auf deinem System kaputtgemacht.
Der cupsd (also cups.service) konnte vermutlich schon vor dem Update nicht beim Booten gestartet werden.
Dadurch das cups.socket aktiviert war und im Netwerk lauschte, wurde das allerdings kaschiert, da cupsd dann sowieso bei Bedarf von cups.socket gestartet wurde.
Nach dem Update lauscht cups.socket allerdings nicht mehr im Netzwerk (nur auf localhost), dadurch ist dein Workaround für das eigentliche Problem weggefallen.
Durch die händisch angelegte cups.socket Datei verhält sich cups.socket jetzt wieder wie vor dem Update (lauscht also auch im Netzwerk) und alles funktioniert wieder.
Die händisch angelegte cups.socket sollte jedenfalls auch nach zukünftigen Updates weiter funktionieren (Konfigurationsdateien in /etc werden durch Updates nicht überschrieben/geändert).

Jetzt ist halt die Frage ob du zufrieden bist, oder ob du das eigentliche Problem (cups.service startet nicht beim Booten) beheben willst.
Ich bin nicht wirklich Experte in Sachen cups, aber ich würd mal als erstes in den Logfiles nach Hinweisen suchen (am Besten direkt nach dem Booten, also ohne cups händisch zu starten oder was zu drucken probieren):
/var/log/cups/error_log
“sudo journalctl -b -x -u cups”

#15

Ich habe das genau gleiche Problem wie beeblebrox421966](https://forums.opensuse.org/member.php/78473-beeblebrox421966)

Es war bei mir immer möglich, cups mit “systemctl start cups” zu starten.

Nachdem all die aufgelisteten Tips bei mir nichts gefruchtet haben, habe ich mich zu einem unschönen Workaround entschlossen:
Ich habe einfach in der /etc/init.d/after.local den Eintrag:
systemctl start cups
hinzugefügt. Unschön, aber ich bin mal mein Problem los. Sollte wieder ein cups-update folgen, werde ich mal schauen, ob ich das immer noch brauche.

Übrigens: Ich habe in anderen Foren gesehen, dass eine x86_64 betroffen war. Auch ich habe eine x86_64. Kann es sein, dass nur in dieser Version das Problem auftritt?

Erwin

#16

Nein. Ich habe auch x86_64 und bei mir startet cups einwandfrei.

Außerdem, wie gesagt, die einzige Änderung im letzten Update war, dass cups.socket nur mehr auf dem eigenen Rechner lauscht.
Wenn aus irgendeinem Grund cupsd nicht gestartet werden kann, hat das sicher nichts mit dem letzten Update zu tun.

#17

Hi wolfi,
das hatte ich in dem Hin und Her ganz vergessen dass wir cups.socket auf disabled gesetzt hatten. Hätte ich auch selbst drauf kommen können :wink:

Ich habe mittlerweile wieder die cups 1.5.4 12.4.1 drauf, sockets aktiviert, cups.socket entsprechend geändert und es funktioniert wieder.

Danke für die Hilfe.

Gruss

Jürgen

#18

Hallo,

ich habe genau das gleiche Problem unter OS 13.1 und Cups 1.5.4. (2 Netzwerkdrucker) Bis letzte Woche nach dem Cups-Update nach dem Booten der cups.service im Status enabled aber inaktiv ist.
linux:/home/rene # systemctl status cups.service
cups.service - CUPS Printing Service
Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)
Active: inactive (dead)

linux:/home/rene # systemctl start cups.service

linux:/home/rene # systemctl status cups.service
cups.service - CUPS Printing Service
Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)
Active: active (running) since Do 2014-01-30 21:51:41 CET; 14s ago
Main PID: 2187 (cupsd)
CGroup: /system.slice/cups.service
└─2187 /usr/sbin/cupsd -f

Jan 30 21:51:41 linux systemd[1]: Started CUPS Printing Service.
Jan 30 21:51:41 linux cupsd[2187]: No limit for Validate-Job defined in policy allowallforanybody and no suitable template found.
Jan 30 21:51:41 linux cupsd[2187]: No limit for Cancel-Jobs defined in policy allowallforanybody and no suitable template found.
Jan 30 21:51:41 linux cupsd[2187]: No limit for Cancel-My-Jobs defined in policy allowallforanybody and no suitable template found.
Jan 30 21:51:41 linux cupsd[2187]: No limit for Close-Job defined in policy allowallforanybody and no suitable template found.
Jan 30 21:51:41 linux cupsd[2187]: No limit for CUPS-Get-Document defined in policy allowallforanybody and no suitable template found.
Jan 30 21:51:41 linux cupsd[2187]: No JobPrivateAccess defined in policy allowallforanybody - using defaults.
Jan 30 21:51:41 linux cupsd[2187]: No JobPrivateValues defined in policy allowallforanybody - using defaults.
Jan 30 21:51:41 linux cupsd[2187]: No SubscriptionPrivateAccess defined in policy allowallforanybody - using defaults.
Jan 30 21:51:41 linux cupsd[2187]: No SubscriptionPrivateValues defined in policy allowallforanybody - using defaults.

Auch das Netzwerk ist mit ifup so konfiguriert, dass dies beim Booten schon zur Verfügung steht und auf Cups-Server “gelauscht” werden kann.

Nach einer Neuinstallation von OS 13.1 ist das Problem behoben, nach den Update wieder da. Ich habe auch alles hier genannte schon probiert, doch ohne Erfolg.

Gruß

René

#19

Was hast du alles schon probiert?
Lege eine Datei /etc/systemd/system/cups.socket an mit genau dem Inhalt wie von mir schon geschrieben:

[Unit]
WantedBy=sockets.target
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=631
ListenDatagram=0.0.0.0:631
BindIPv6Only=ipv6-only

[Install]

Dann rufe “sudo systemctl enable cups.socket” auf und alles ist genau so wie vor dem Update.

#20

Hallo

Ein CUPS-Update ist nun für die Prüfung von der OBS-Projekt verfügbar

Refer

https://bugzilla.novell.com/show_bug.cgi?id=857372#c75

Entfernen / etc / systemd / system / cups.socket (wenn man es erstellt).

Fügen Sie das Repository-und Update-…

http://download.opensuse.org/repositories/Printing/openSUSE_13.1/