Drucken geht nicht mehr, cups Server nicht aktiv, localhost:631 keine Verbindung

Deutsch (German) Anwendungen
#1

Hallo zusammen,
seit einigen Tagen (nach Updates?) kann ich nicht mehr drucken. (EPSON Netzwerkdrucker)
Bis vor ca. 1 Woche wa noch alles in Ordnung.
Ich habe die Suse 13.1 (gleiches Problem in 12.3).
Bei Aufruf von Cups kommt bei localhost:631 -> keine Verbindung.
Starte ich mit “/usr/sbin/cupsd -f” den Service funktioniert wieder alles.

Hat jemand das gleiche Problem oder bin ich alleine betroffen?
Das Problem schaut fast identisch aus, wie bei diesem Problem:Ich habe das nachvollzogen, es scheint bei mir aber alles in Ordnung zu sein (aus damaliger Sicht).

Welche Unterlagen bräuchte man zu einer weiteren Diagnose?

#2

Hm, ich sehe im 13.1 Update repo kein kürzliches Update das auch nur irgendwie mit cups in Zusammenhang steht…

Bei Aufruf von Cups kommt bei localhost:631 -> keine Verbindung.
Starte ich mit “/usr/sbin/cupsd -f” den Service funktioniert wieder alles.

Gehts auch, wenn du stattdessen “sudo systemctl start cups” aufrufst?
Was sagt “sudo systemctl status cups”, wenn cups nicht läuft?

Vielleicht ist ja nur der cups Dienst deaktiviert/disabled und wird deshalb nicht automatisch beim Booten gestartet?

#3

Richtig. Hatte ich auch schon nachgeschaut. Letzte Änderung von CUPS V1.5.4-12.17.1 -> 17. Feb 2015.

ps -A|grep cups
[keine Ausgabe]


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

“sudo systemctl start cups” —> funktioniert.

#4

Tja, also das Service ist “enabled” (wird also beim Booten gestartet), aber scheinbar geht beim Starten was schief…
Kannst du bitte “systemctl status cups” als root ausführen (z.B. mit sudo)? Dann sollten mehr Informationen geliefert werden, warum es nicht starten konnte.

Und die Ausgabe von “systemctl status cups.socket” wäre evtl. auch interessant.

#5

Die vorherige Ausgabe war schon als root.
Hier noch mal beide unter root:

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

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

INN:~ #
#6

Ok, dann sollte zumindest /var/log/cups/error_log Aufschluss geben, warum er nicht startet.

Allerdings:

INN:~ # systemctl status cups.socket
cups.socket - CUPS Printing Service Sockets
   Loaded: loaded (/usr/lib/systemd/system/cups.socket; disabled)
   Active: inactive (dead)

Probier mal das Socket zu enablen, das startet cups (falls notwendig) wann immer ein Programm probiert auf localhost:631 zuzugreifen, und sollte daher dein Problem “lösen”.

sudo systemctl enable cups.socket
#7

Zuerst die gute Nachricht:
Mit “sudo systemctl enable cups.socket” und Neustart war CUPS wieder erreichbar.
Ich hoffe, dass dies dauerhaft ist.
Ich frag mich nur, wieso oder wer und warum da was geändert hat?
Ich habe bewusst nichts geändert.
Damit ein Riesen Danke an Dich.

Ich poste aber noch mal das aktuelle Log.
Ich kann aber nichts sehen, was die Ursache wäre.

E [28/Apr/2015:15:44:28 +0200] Returning HTTP Forbidden for CUPS-Add-Modify-Printer (ipp://localhost/printers/epsondec07c) from localhost
E [28/Apr/2015:15:45:02 +0200] cupsdAuthorize: pam_authenticate() returned 10 (User not known to the underlying authentication module)!
E [28/Apr/2015:15:45:04 +0200] cupsdAuthorize: pam_authenticate() returned 10 (User not known to the underlying authentication module)!
E [02/Jun/2015:17:44:13 +0200] cupsdAuthorize: pam_authenticate() returned 7 (Authentication failure)!
E [02/Jun/2015:17:46:01 +0200] Unable to bind socket for address [v1.::1]:631 - Address already in use.
E [02/Jun/2015:17:46:01 +0200] Unable to bind socket for address 127.0.0.1:631 - Address already in use.
E [02/Jun/2015:17:46:01 +0200] Unable to bind broadcast socket - Address already in use.
E [02/Jun/2015:17:46:55 +0200] Unable to remove /var/run/cups/certs/0!
E [06/Jun/2015:19:25:05 +0200] Browsing=1
E [06/Jun/2015:19:25:05 +0200] BrowseLocalProtocols=0
E [06/Jun/2015:19:25:05 +0200] BrowseRemoteProtocols=1
E [06/Jun/2015:19:25:05 +0200] BROWSE_CUPS=1
E [06/Jun/2015:19:25:05 +0200] Unable to bind socket for address [v1.::1]:631 - Address already in use.
#8

Sollte schon.
Durch das Socket lauscht systemd selbst auf Port 631 und startet cups bei Bedarf sobald ein Programm darauf zugreift, also z.B. drucken will.
Es ist also egal, ob cups bereits während des Bootens gestartet wird oder nicht, eigtl. ist das dann gar nicht notwendig.

Ich frag mich nur, wieso oder wer und warum da was geändert hat?
Ich habe bewusst nichts geändert.

Tja, das kann ich dir auch nicht sagen. Ich bin mir jetzt nicht mal sicher ob cups.socket in 13.1 standardmäßig aktiv sein sollte oder nicht.

Allerdings sollte cups ja auch ohne dem socket starten.

Ich poste aber noch mal das aktuelle Log.
Ich kann aber nichts sehen, was die Ursache wäre.

E [28/Apr/2015:15:44:28 +0200] Returning HTTP Forbidden for CUPS-Add-Modify-Printer (ipp://localhost/printers/epsondec07c) from localhost
E [28/Apr/2015:15:45:02 +0200] cupsdAuthorize: pam_authenticate() returned 10 (User not known to the underlying authentication module)!
E [28/Apr/2015:15:45:04 +0200] cupsdAuthorize: pam_authenticate() returned 10 (User not known to the underlying authentication module)!
E [02/Jun/2015:17:44:13 +0200] cupsdAuthorize: pam_authenticate() returned 7 (Authentication failure)!
E [02/Jun/2015:17:46:01 +0200] Unable to bind socket for address [v1.::1]:631 - Address already in use.
E [02/Jun/2015:17:46:01 +0200] Unable to bind socket for address 127.0.0.1:631 - Address already in use.
E [02/Jun/2015:17:46:01 +0200] Unable to bind broadcast socket - Address already in use.
E [02/Jun/2015:17:46:55 +0200] Unable to remove /var/run/cups/certs/0!
E [06/Jun/2015:19:25:05 +0200] Browsing=1
E [06/Jun/2015:19:25:05 +0200] BrowseLocalProtocols=0
E [06/Jun/2015:19:25:05 +0200] BrowseRemoteProtocols=1
E [06/Jun/2015:19:25:05 +0200] BROWSE_CUPS=1
E [06/Jun/2015:19:25:05 +0200] Unable to bind socket for address [v1.::1]:631 - Address already in use.

Hm, also das würde darauf hindeuten, dass bereits ein Dienst auf Port 631 läuft.
Keine Ahnung was das sein könnte, nach dem vollständigen Booten gehts ja auch…

Die Meldungen über “Authentification failure” hören sich auch nicht grade gut an, dürften aber scheinbar nicht mit deinem Problem zusammenhängen.

#9

Jetzt steht im log nur noch die TCP6 Meldung:

E [07/Jun/2015:11:29:38 +0200] Browsing=1
E [07/Jun/2015:11:29:38 +0200] BrowseLocalProtocols=0
E [07/Jun/2015:11:29:38 +0200] BrowseRemoteProtocols=1
E [07/Jun/2015:11:29:38 +0200] BROWSE_CUPS=1
E [07/Jun/2015:11:29:38 +0200] Unable to bind socket for address [v1.::1]:631 - Address already in use.

Wie man am log sieht war vom 28. April bis um Juni gar kein Eintrag.

Ich hbe noch mal weitergesucht und anscheinend haben noch mehrere Probleme damit.
Als Hinweis las ich dann von netstat → 

netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:33707           0.0.0.0:*               LISTEN      763/rpc.statd       
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/init              
tcp        0      0 0.0.0.0:20048           0.0.0.0:*               LISTEN      758/rpc.mountd      
tcp        0      0 0.0.0.0:59762           0.0.0.0:*               LISTEN      -                   
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1512/cupsd          
tcp        0      0 192.168.2.105:51274     52.24.139.178:443       ESTABLISHED 1429/firefox        
tcp        0      0 192.168.2.105:42141     188.111.53.49:80        ESTABLISHED 1429/firefox        
tcp        0      0 192.168.2.105:40808     173.194.39.4:80         ESTABLISHED 1429/firefox        
tcp        0      0 192.168.2.105:50322     173.194.39.0:443        ESTABLISHED 1429/firefox        
tcp        0      0 :::2049                 :::*                    LISTEN      -                   
tcp        0      0 :::57900                :::*                    LISTEN      -                   
tcp        0      0 :::47374                :::*                    LISTEN      763/rpc.statd       
tcp        0      0 :::111                  :::*                    LISTEN      1/init              
tcp        0      0 :::20048                :::*                    LISTEN      758/rpc.mountd      
tcp        0      0 :::631                  :::*                    LISTEN      1/init              
INN:~ #

Da scheint 1/init den Port zu benützen. Soll das so sein?
War ja anscheinend nicht immer so, sonst hätte es ja vorher schon Meldungen gegeben?

#10

Und was hast du geändert? :wink:

Wenn cups.socket nicht aktiv ist, sollte niemand Port 631 benutzen.
Sowas kann aber durch eine falsche “Listen” Direktive in cupsd.conf verursacht werden, denke ich.

Mit aktivem cups.socket ists aber eh egal und vermutlich brauchst du Netzwerkzugriff auf deinen Cups über IPv6 sowieso nicht. Hast du überhaupt ein IPv6 Netzwerk?

Ich hbe noch mal weitergesucht und anscheinend haben noch mehrere Probleme damit.

Probleme sollte es eigentlich nur dann geben, wenn die Konfigurationen nicht zusammenpassen.
Z.B. wenn ein Fehler in der cupsd.conf ist, oder wenn das Socket aktiv ist aber auf anderen Ports lauscht als cups selber.

Da scheint 1/init den Port zu benützen. Soll das so sein?

Wenn cups.socket aktiv ist, ja.
Wie gesagt, dann lauscht systemd (also init) auf Port 631 und startet bei Bedarf cupsd wenn ein Programm sich verbinden will.

PS: Wenn cups.socket aktiv ist, solltest du auch einfach cupsd.service abschalten können (weil eben systemd den cupsd bei Bedarf startet). Vielleicht würde das auch die “Fehlermeldung” verhindern.

#11

Also geändert habe ich bewusst in keiner der cups-Dateien etwas.
Ich hab natürlich auch kein IPV6 Netzwerk.
Ich habe nur die üblichen Updates installiert.
Durch welche Anwendungen wird denn die cupsd.conf geändert?
Die hat komischerweise ein neueres Datum (02.06.2015). Ich habe aber dort nichts editiert.

Ich habe ja noch die 13.2 installiert. Die ist ziemlich jungfräulich.
Dort sind der cups.service und der cups.socket nach dem Booten geladen und enabled?
Im Gegensatz - jetzt - zu 13.1, wo der cups.service erst nach Aufruf eines Druckvorangs enabled wird.
Wo wird das denn bestimmt, wann geladen und enabled wird?
Und welcher Zustand sollte denn der “Richtige” sein?

#12

Wieso “natürlich”? IPv6 gibts mittlerweile seit fast 20 Jahren, und IPv4 wird schön langsam zu klein (oder ist eigentlich schon seit Jahren zu klein wenn mans global betrachtet).
Allerdings in einem Heimnetzwerk mit ein, zwei Rechnern ists natürlich nicht notwendig, und soweit ich weiß verteilen die meisten Router normalerweise auch nur IPv4 Adressen sofern du sie nicht anders konfigurierst…

Ich habe nur die üblichen Updates installiert.

Tja, was heißt “übliche Updates”?
Wie gesagt, ich sehe kein offizielles Update in letzter Zeit das irgendeinen Einfluss auf cups haben könnte.
Mit Updates von Dritt-Repos siehts dann aber vermutlich wieder anders aus.

Durch welche Anwendungen wird denn die cupsd.conf geändert?
Die hat komischerweise ein neueres Datum (02.06.2015). Ich habe aber dort nichts editiert.

YaST->Hardware->Drucker oder die CUPS-Konfigurationsseite http://localhost:631/ z.B.

Wenn ich dich richtig verstehe, hast du das Problem seit 2.Juni, also hängts scheinbar mit einer Änderung an der Datei zusammen.
Evtl. gibst noch eine Sicherheitskopie? (z.B. cupsd.conf.O)
Dann könnte man schauen was genau geändert wurde.

Ich habe ja noch die 13.2 installiert. Die ist ziemlich jungfräulich.
Dort sind der cups.service und der cups.socket nach dem Booten geladen und enabled?

Sollte ja eigentlich bei 13.1 auch so sein, denke ich.

Im Gegensatz - jetzt - zu 13.1, wo der cups.service erst nach Aufruf eines Druckvorangs enabled wird.

Nein.
cups.service wird nach Aufruf eines Druckvorgangs gestartet (von cups.socket), enabled ist es ja sowieso laut deines Outputs.

“enabled” heißt, dass es automatisch beim Booten gestartet wird.

Wo wird das denn bestimmt, wann geladen und enabled wird?

In /etc/systemd/system, du solltest aber systemctl bzw. YaST->System->Services Manager dafür verwenden, nicht bei den Dateien selbst rumpfuschen.

Und welcher Zustand sollte denn der “Richtige” sein?

“Richtig” für was?

Wenn du cups.service beim Booten automatisch starten willst, muss er “enabled” sein.
Allerdings wird er dann bedingungslos gestartet (außer es geht was schief), und läuft also auch (unnötig) wenn du sowieso nicht drucken willst.
Das ist der Vorteil von cups.socket, das startet cups erst wenn wirklich gedruckt werden soll.

Im Normalfall sollte das auch ausreichen (und ist sogar vorteilhaft, weil cups eben nicht unnötig läuft), kann aber zu Problemen mit der automatischen Erkennung von Netzwerkdruckern/Druckern auf anderen Rechnern geben, weil dafür eben der cupsd von sich aus Broadcasts durchs Netzwerk schicken muss.

Wenn cups.service enabled ist, brauchst du cups.socket eigentlich nicht und umgekehrt.

#13

Ich habe ausser dem Packman-Repo nur Repos von “download.opensuse.org”.

Wenn ich dich richtig verstehe, hast du das Problem seit 2.Juni, also hängts scheinbar mit einer Änderung an der Datei zusammen.
Evtl. gibst noch eine Sicherheitskopie? (z.B. cupsd.conf.O)
Dann könnte man schauen was genau geändert wurde.

Die cupsd.conf.O gibt es noch. Ich schaue sie mir demnächst mal an.
Bist Du interessiert?

cups.service wird nach Aufruf eines Druckvorgangs gestartet (von cups.socket), enabled ist es ja sowieso laut deines Outputs.

“enabled” heißt, dass es automatisch beim Booten gestartet wird.

In /etc/systemd/system, du solltest aber systemctl bzw. YaST->System->Services Manager dafür verwenden, nicht bei den Dateien selbst rumpfuschen.

Wenn du cups.service beim Booten automatisch starten willst, muss er “enabled” sein.
Allerdings wird er dann bedingungslos gestartet (außer es geht was schief), und läuft also auch (unnötig) wenn du sowieso nicht drucken willst.
Das ist der Vorteil von cups.socket, das startet cups erst wenn wirklich gedruckt werden soll.

Im Normalfall sollte das auch ausreichen (und ist sogar vorteilhaft, weil cups eben nicht unnötig läuft), kann aber zu Problemen mit der automatischen Erkennung von Netzwerkdruckern/Druckern auf anderen Rechnern geben, weil dafür eben der cupsd von sich aus Broadcasts durchs Netzwerk schicken muss.

Wenn cups.service enabled ist, brauchst du cups.socket eigentlich nicht und umgekehrt.

Ich habe mich vertan. Statt enabled meinte ich “active” (kein cups Prozess). Entschuldigung.

#14

Tja, da gibts hunderte, oder vielleicht sogar tausende.
Da können alle möglichen “Updates” dabei sein…

Die cupsd.conf.O gibt es noch. Ich schaue sie mir demnächst mal an.
Bist Du interessiert?

Tja, “interessiert” ist vielleicht der falsche Ausdruck…

Aber du kannst ja mal einen diff posten.

sudo diff -u /etc/cups/cupsd.conf.O /etc/cups/cupsd.conf

Das sollte die exakten Änderungen zeigen.

Ich habe mich vertan. Statt enabled meinte ich “active” (kein cups Prozess). Entschuldigung.

Ok. Habe ich mir fast gedacht… :wink:

Also wie gesagt, cups.service startet den cupsd-Prozess einmal beim Booten (bzw. wenn du es manuell nochmal startest), cups.socket macht das wann immer ein Programm auf cups zugreifen will falls cupsd nicht läuft (also eigentlich startet es in dem Fall ja cups.service). Letzteres hilft also auch falls cupsd abstürzen sollte.

Ich würd sagen, lass einfach das Socket enabled, dann sollte es eigentlich keine Probleme geben. Es ist ja auch standardmäßig enabled soweit ich mich erinnere…

#15 
diff -s -u /etc/cups/cupsd.conf.O /etc/cups/cupsd.conf
Files /etc/cups/cupsd.conf.O and /etc/cups/cupsd.conf are identical

Anscheinend wurde die Datei ohne Änderung geschrieben.
Das Datum von conf.O war 06.02.2015 und von conf 02.06.2015!
Sei’s drum. Ich mach es jetzt so, wie Du sagst.
Ich bin ja froh, dass der Drucker wieder da ist.

#16

Darf ich Dich doch nochmal belästigen?
Ich wollte Ausprobieren, ob ich cups nach dem Booten aktiv bekomme, so wie es in der 13.2 ist.

In YAST/Dienste sind 2 Services vorhanden mit Namen cups und cupsd.
Braucht man die beide? Sonst ist immer nur “cups” vorhanden.

Beide Dienste stehen nach dem Booten immer auf inaktiv. Ich setze beide auf aktiv.

Der angezeigte Status (in YAST) sagt und zwar für beide identisch folgendes:

 cups.service - CUPS Printing Service    Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)    Active: active (running) since Tue 2015-06-09 13:37:23 CEST; 5min ago  Main PID: 2667 (cupsd)    CGroup: /system.slice/cups.service            `-2667 /usr/sbin/cupsd -f 
Jun 09 13:37:23 INN cupsd[2667]: No limit for Validate-Job defined in policy allowallforanybody and no suitable template found. Jun 09 13:37:23 INN cupsd[2667]: No limit for Cancel-Jobs defined in policy allowallforanybody and no suitable template found. Jun 09 13:37:23 INN cupsd[2667]: No limit for Cancel-My-Jobs defined in policy allowallforanybody and no suitable template found. Jun 09 13:37:23 INN cupsd[2667]: No limit for Close-Job defined in policy allowallforanybody and no suitable template found. Jun 09 13:37:23 INN cupsd[2667]: No limit for CUPS-Get-Document defined in policy allowallforanybody and no suitable template found. Jun 09 13:37:23 INN cupsd[2667]: No JobPrivateAccess defined in policy allowallforanybody - using defaults. Jun 09 13:37:23 INN cupsd[2667]: No JobPrivateValues defined in policy allowallforanybody - using defaults. Jun 09 13:37:23 INN cupsd[2667]: No SubscriptionPrivateAccess defined in policy allowallforanybody - using defaults. Jun 09 13:37:23 INN cupsd[2667]: No SubscriptionPrivateValues defined in policy allowallforanybody - using defaults. Jun 09 13:37:23 INN systemd[1]: Started CUPS Printing Service.

I[size=2]st hier ein “cups[d]” zuviel?

Und wie bekomme ich den Cups permanent übers booten hinaus aktiv?
[/size]

#17

In 13.1 enthält cups.service folgende Zeile:

Alias=cupsd.service

Das ist also beides der selbe Dienst.

Beide Dienste stehen nach dem Booten immer auf inaktiv. Ich setze beide auf aktiv.

Du kannst den nicht “auf aktiv setzen”. Du kannst ihn höchstens starten.
Wenn er nicht gestartet ist, bzw. beim Starten was schiefläuft, ist er “inaktiv”.

Ist hier ein “cups[d]” zuviel?

Nein, sh. oben.

Und wie bekomme ich den Cups permanent übers booten hinaus aktiv?

Finde den Fehler warum cups beim Booten nicht erfolgreich startet und behebe ihn. :wink:

Oder bleib beim Socket, wie gesagt der startet den cups immer bei Bedarf, nicht nur beim Booten.

Da du ja leider doch keine Sicherheitskopie von cupsd.conf hast, kann man auch nicht sagen was sich dort geändert hat.
Wenn du willst kannst du auch die gesamte Datei posten, aber ich bin jetzt auch nicht wirklich ein Experte dafür.

#18

Das erklärt es. hat sicher seinen Sinn.

Du kannst den nicht “auf aktiv setzen”. Du kannst ihn höchstens starten.
Wenn er nicht gestartet ist, bzw. beim Starten was schiefläuft, ist er “inaktiv”.

In YAST heisst das auf aktiv setzen (übrigens in jeder Version anders), was gleichbedeutend mit starten ist.

Finde den Fehler warum cups beim Booten nicht erfolgreich startet und behebe ihn. :wink:

Womit ich wieder bei meiner Frage aus Nr. 1 angelangt in: “Welche Unterlagen bräuchte man zu einer weiteren Diagnose?”
Genauer. Wo kann ich etwas über den Startfehler sehen, finden. Alle Logs, die ich bisher angeschaut habe haben mich nicht wirklich weitergebracht.:’(

Oder bleib beim Socket, wie gesagt der startet den cups immer bei Bedarf, nicht nur beim Booten.

Solang das andere nicht geht (und wahrscheinlichauch dann wieder, wenn es wieder geht) bleib ich beim Socket.
Mich “wurmt” einfach, warum auf einmal die andere Methode nicht mehr geht und ich würds gern wissen warum.

Hier die cupsd.conf:

LogLevel warn
SystemGroup sys root
Listen localhost:631
Listen /var/run/cups/cups.sock
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols CUPS
DefaultAuthType Basic
WebInterface Yes
<Location />
  Order allow,deny
  Allow 127.0.0.2
</Location>
<Location /admin>
  Order allow,deny
</Location>
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
</Location>
<Policy default>
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  <Limit Create-Job Print-Job Print-URI Validate-Job>
    Order deny,allow
  </Limit>
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Authenticate-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit All>
    Order deny,allow
  </Limit>
</Policy>
<Policy authenticated>
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  <Limit Create-Job Print-Job Print-URI Validate-Job>
    AuthType Default
    Order deny,allow
  </Limit>
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Cancel-Job CUPS-Authenticate-Job>
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit All>
    Order deny,allow
  </Limit>
</Policy>
<Policy allowallforanybody>
  <Limit All>
    Order deny,allow
    Allow from all
  </Limit>
</Policy>
DefaultPolicy default
#19

Ist vermutlich eine Kompatibilitäts-Sache.

In YAST heisst das auf aktiv setzen (übrigens in jeder Version anders), was gleichbedeutend mit starten ist.

Tut mir leid, ich habe gerade in meiner 13.1 VM nachgeschaut: sowohl dort als auch hier in 13.2 heisst der Knopf “Start/Stop”. Evtl. meinst du das veraltete Runlevel Modul? Das wurde nie an systemd angepasst und stattdessen in 13.1 durch die “Dienste-verwaltung” ersetzt (hat auch gar nicht mehr 100%ig funktioniert). Bei einer 13.1 Neuinstallation ists auch gar nicht dabei, es bleibt aber installiert wenn du von einer älteren Version auf 13.1 upgradest.

“Auf aktiv setzen” macht ja auch keinen Sinn, wie gesagt: du kannst einen Dienst starten, danach sollte er “aktiv” sein, aber wenn beim Starten was schiefläuft bleibt er trotz Startens “inaktiv”. Da kannst du “setzen” was du willst, wenn er nicht läuft, dann läuft er nicht… :wink:

Womit ich wieder bei meiner Frage aus Nr. 1 angelangt in: “Welche Unterlagen bräuchte man zu einer weiteren Diagnose?”
Genauer. Wo kann ich etwas über den Startfehler sehen, finden. Alle Logs, die ich bisher angeschaut habe haben mich nicht wirklich weitergebracht.:’(

Tja, an sich in /var/log/cups/error_log, aber das war ja auch nicht sehr aufschlussreich, zumindest sagt es nicht welches andere Programm evtl. den Port bereits belegt.
Evtl. könnte es weiter helfen den “LogLevel” in der cups Konfiguration zu erhöhen, aber ich glaube fast nicht.

Dass es kein allgemeines Problem ist (du kannst den cups.service ja im laufenden System einwandfrei starten), macht es auch nicht einfacher es genauer zu untersuchen.

Ich wüsste jetzt auch nicht was den Port beim Booten belegen könnte… Außer cups.socket (also systemd/init), das hattest du aber ja deaktiviert.

Solang das andere nicht geht (und wahrscheinlichauch dann wieder, wenn es wieder geht) bleib ich beim Socket.
Mich “wurmt” einfach, warum auf einmal die andere Methode nicht mehr geht und ich würds gern wissen warum.

Naja, ohne irgendeine Ahnung zu haben, was für Updates installiert wurden (oder was sonst geändert wurde), ists auch schwer zu raten.
Und weitere Berichte über ähnliche Probleme sind mir in letzter Zeit auch nicht bekannt, schon gar nicht für 13.1.

Hier die cupsd.conf:

Schaut eigentlich soweit in Ordnung aus.
Am ehesten würds ja an einer falschen “Listen” Direktive liegen, aber dann sollte cups auch später nicht starten.
Außerdem ist die bei mir in 13.2 exakt genauso, und mein cups.service startet einwandfrei.

Das einzige was ich mir evtl. noch vorstellen könnte ist, dass vielleicht der Netzwerk-Dienst noch nicht gestartet ist, wenn cups probiert zu starten. Das könnte evtl. Probleme machen wenn cups auf dem Port 631 lauschen will.
Verwendest du ifup oder NetworkManager? Probier vielleicht mal umzuschalten und das cups.socket wieder zu deaktivieren. Startet cups.service dann?

#20

Ich habe mal ein eher großes Problem, das vermutlich auf einem Bug beruht.

Wenn man in der /etc/cups/cupsd.conf die

DefaultPolicy allowallforanybody

einstellt (Standard war default)

dann ist der cupsd so gut wie tot, er reagiert nicht mehr auf lpstat -v und Drucken ist passei. Nach dem Zurückstelle+Neustart klappt wieder Alles.

Das waren seine letzten Worte:

D [26/Jun/2015:20:09:23 +0200] CUPS-Get-Printers
D [26/Jun/2015:20:09:23 +0200] Returning HTTP Unknown for CUPS-Get-Printers (no URI) from localhost

nach ctrl-c ist der prompt nach lpstat -v wieder wieder frei und es erscheint:

D [26/Jun/2015:20:10:30 +0200] cupsdReadClient: 12 WAITING Closing on EOF
D [26/Jun/2015:20:10:30 +0200] cupsdCloseClient: 12
D [26/Jun/2015:20:10:30 +0200] cupsdSetBusyState: newbusy=“Not busy”, busy=“Active clients”

Das müsste ein Bug in der aktuellen cups-Version sein. ich habe cups-1.5.4-21.9.1.x86_64
unter OpenSuSE 13.2 installiert. Gleiches Verhalten auf aktuellen 32Bit Systemen. Ich weiss,
die o.g. policy ist etwas gewagt, weil unsicher aber sehr beliebt in meiner Firma. Habe fast alle Bugreports durch. Unter OpenSuSe 12.2 und 13.1 gabs so etwas nicht.

Sieht mir nach einem Programmierfehler aus.