I have systemd and cups installed and configured. Cups works fine if I start it manually with "systemctl start cups.service", but I am having to do that every reboot to get it to work. I have already tried "systemctl enable cups.service", and it didn't change anything. I've been told its supposed to be socket activated, but it is not activating automatically when I try and print something, I always have to manually start the service.
I can't find any reason why this is refusing to work, and its driving me insane. The wiki has basically nothing on systemd + cups specific issues. Any ideas? I don't care if its on all the time, or socket activated I just want it to work.
Last edited by bwat47 (2012-08-08 00:16:13)
Found the issue:
currently running "systemctl enable cups.service" (I the same issue whether this was enabled or disabled) does this, which doesn't seem to work at all:
ln -s '/usr/lib/systemd/system/cups.path' '/etc/systemd/system/multi-user.target.wants/cups.path'
so I manually ran: sudo ln -s '/usr/lib/systemd/system/cups.service' '/etc/systemd/system/multi-user.target.wants/cups.service' which fixed the issue for me.
The unit file for cups.socket seems messed up in the latest systemd version (and was only slightly less messed up in the previous version). I installed the following corrected (?) unit file as /etc/systemd/system/cups.socket:
Description=CUPS Printing Service Sockets
Then I ran
$ systemctl enable cups.service
and everything works as expected here. The unit file in the systemd package has an empty [Install] section, which prevents systemctl enable cups.service from enabling the socket. It also had ListenStream=631 instead of ListenStream=0.0.0.0:631, which for some reason resulted in the cups web interface on localhost:631 to be non-responsive unless, for example, an lpq query had previously triggered the socket and thus started the cups.service.
thanks man, that worked
That didn't work for me. I get thousands of these messages every second:
Sep 20 14:38:04 t1000 systemd: cups.service start request repeated too quickly, refusing to start. Sep 20 14:38:04 t1000 systemd: cups.service start request repeated too quickly, refusing to start. Sep 20 14:38:04 t1000 systemd: cups.service start request repeated too quickly, refusing to start. Sep 20 14:38:04 t1000 systemd: cups.service start request repeated too quickly, refusing to start. Sep 20 14:38:04 t1000 systemd: cups.service start request repeated too quickly, refusing to start.
I just disabled it for now so that it won't run my CPU and HD ragged while I sleep. I'll try to figure out what went wrong tomorrow.
I'm going to post a new topic as this one is marked "Solved" and the fix did not work for me.
Last edited by Convergence (2012-09-22 18:03:56)
It's a very deadly weapon to know what you're doing
--- William Murderface
I came here with same problems, but I managed to solve my issue, is not "cups", is"cupsd":
systemctl start cupsd.service
* PC: Intel Core 2 DUO E6550 @ 2.33 GHz with 2 GB RAM: Archlinux-i686 with xfce4.
* Laptop: Intel Core 2 DUO T6600 @ 2.20 GHz with 4 GB RAM: Archlinux-x86-64 with xfce4.
* AUR contributor.
I had the same problem, and solved it adding first some modules and starting the the cups service with systemctl
---- AS OF OCT 2014 -----
For cups 2.0.0, the service name has been changed to org.cups.cupsd.service instead of cups.service. This package is available in extra from October 31, 2014. When upgrading to version 2.0.0, it is necessary to manually disable the old service, otherwise broken symbolic links will be left in /etc/systemd/system/ subdirectories and systemd will warn about non-existent services.
systemctl enable org.cups.cupsd.service
Be careful of ancient threads
This one had been dormant for two and a half years.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
You assume people are rational and influenced by evidence. You must not work with the public much. -- Trilby
How to Ask Questions the Smart Way