When enabling the cups service in systemd (so that it is started on boot), it results in the error "Unable to bind socket for address [v1.::1]:631 - Address already in use." in "/var/log/cups/error_log", and cups not being started. However, cups can be properly initialized through a script in /etc/NetworkManager/dispatcher.d/ Reproducible: Always Steps to Reproduce: 1.enable cups service at boot with "systemctl enable cups.service" 2.reboot Actual Results: cups is not listening in http://localhost:631/ and the error message"Unable to bind socket for address [v1.::1]:631 - Address already in use." shows up in /var/log/cups/error_log Expected Results: no error message in the log and cups listening in http://localhost:631/
Its the cups.socket that's causing the problem. Both Fedora and SuSE had the problem and both removed the IP socket activation. Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=842365 - inaccessible, but see http://pkgs.fedoraproject.org/cgit/cups.git/commit/cups-systemd-socket.patch?id=6ef39188975c03f6132a98c8cad20ce80b3d95d9) SuSE: https://bugzilla.novell.com/show_bug.cgi?id=795624
Commented out; #ListenStream=631 #BindIPv6Only=ipv6-only # cat /usr/lib/systemd/system/cups.socket [Unit] Description=CUPS Printing Service Sockets [Socket] ListenStream=/run/cups/cups.sock #ListenStream=631 #BindIPv6Only=ipv6-only [Install] WantedBy=sockets.target Printing works fine and I can access http://localhost:631/ Before I could only access http://127.0.0.1:631/ But this brings up a security bug; https://bugs.gentoo.org/show_bug.cgi?id=450282
*** Bug 497712 has been marked as a duplicate of this bug. ***
@systemd, I would drop all magic related with socket support and that patch that never get finally accepted by upstream and provide only the simply .service file What do you think?
Hmm, sounds sane.
(In reply to Pacho Ramos from comment #4) > @systemd, I would drop all magic related with socket support and that patch > that never get finally accepted by upstream and provide only the simply > .service file > > What do you think? (In reply to Michał Górny from comment #5) > Hmm, sounds sane. Systemd support with a reworked version of the patch (I think) has been integrated in CUPS master branch (leading to cups-2.0). So not all hope is lost. http://www.cups.org/str.php?L3917+P-1+S0+C0+I0+E0+Qsystemd There's no cups gitweb, but the commit id is 1720786e61396c74c14b561e11b22c9c045898c6 Now what we do with cups-1.7 and systemd is basically your decision.
Looks like the accepted patch touches nearly everything, that will likely be a PITA to backport. On the other hand, if we drop socket completely on a new revision and, later, upstream re-introduces it (and also fixes it), will be also ugly for out users (as they will need to migrate to normal service now and, later, they will need to revert it). How many months could cups-2 take to be released by upstream? :/
*** Bug 521192 has been marked as a duplicate of this bug. ***
(In reply to Pacho Ramos from comment #7) > > How many months could cups-2 take to be released by upstream? :/ We've got a rc1 now. I'll have a look at the code later and do a (non-keyworded) bump.
@printing, do you revbumping to drop the patch and simply install this unit files? cat /usr/lib/systemd/system/cups.service [Unit] Description=CUPS Printing Service [Service] ExecStart=/usr/sbin/cupsd -f [Install] Also=cups.path WantedBy=printer.target $ cat /usr/lib/systemd/system/cups.path [Unit] Description=CUPS Printer Service Spool [Path] PathExistsGlob=/var/spool/cups/d* [Install] WantedBy=multi-user.target This will involve I will probably need to add some kind of warning to explain people that they will need to rely on .service file instead of .socket, I was wondering about doing all this as they should get reintroduced and fixed for cups-2... but as socket support looks to be so buggy :/ (although all distributions I have checked are still relying on socket activation... that was another reason I was unsure about how to proceed)
(In reply to Pacho Ramos from comment #10) > @printing, do you revbumping to drop the patch and simply install this unit > files? [...] yes, I'll do such a revbump soon. this needs time in testing though... current ~arch will get fast-stabilized for a sec bug, and I dont want to include this change there yet.
This is fixed in 2.0.0 with systemd support directly from upstream.
