CUPS no longer starts at boot after update

English Install/Boot/Login
1

How can I ensure that CUPS is started during the boot sequence?

YaST2 -> Services Manager shows the two entries cups and cupsd as active. However, after booting is completed, the list of available printers in applications is empty, and the URL localhost:631 just returns “not found”.

However, entering:


> sudo systemctl start cups
>

at a console and then waiting 5 seconds fixes the problem.

The problem appeared first after a usual update (YaST2 -> Software -> Update All Packages (if newer)) which was done around mid or late January on my laptop. The laptop is not connected to any printers by itself, but is used in various networks where printers are available.

About a week ago, I updated my wife’s laptop, and the same problem occurred. Again systemctl start cups fixes the issue, but this is too tedious for her to accept, so I started to investigate now. My wife’s laptop just uses the default repositories + packman.

An update on Friday fixed the issue for me (worked on several attempts), but updating both machines on Monday (10. Feb 2014) caused both machines to fail again (several attempts).

I found this thread here:Cannot access CUPS server after update

which seems quite related, but it talks about a CUPS server, and I do not understand enough whether it applies to a normal CUPS client running on a laptop in order to print wirelessly, and what I should do as a consequence now.

2

Let’s start with output of “systemctl status cups cupsd” immediately after boot.

3

Directly after booting is finished, with no connection to localhost:631 possible:


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




cupsd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)


#

Then I enter:


# systemctl start cups
# systemctl status cups cupsd
cups.service - CUPS Printing Service
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)
   Active: active (running) since Tue 2014-02-11 18:10:40 CET; 2s ago
 Main PID: 1901 (cupsd)
   CGroup: /system.slice/cups.service
           └─1901 /usr/sbin/cupsd -f


Feb 11 18:10:40 machine.url.net systemd[1]: Started CUPS ...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No limit for...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No limit for...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No limit for...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No limit for...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No limit for...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No JobPrivat...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No JobPrivat...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No Subscript...
Feb 11 18:10:40 machine.url.net cupsd[1901]: No Subscript...


cupsd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)


Hint: Some lines were ellipsized, use -l to show in full.
#

…and printing over the network works fine again (no local printer connected).
(I edited the URL above from our real one to “machine.url.net”)

4

I also have this issue (OS 13.1 x64, KDE).

I’ve just gotten used to manually restarting “cupsd” any time I restart the machine
so my printers will work again.


systemctl restart cupsd.service
5

Hi STurtle

It’s a known problem (and especially affects those relying on printing over networks due to socket-activation issues) See this long thread:

https://forums.opensuse.org/showthread.php/494781-Cannot-access-CUPS-server-after-update

and bug report

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

You have two choices currently: Modify cups.socket as suggested in thread, or update CUPS from OBS printing repo (which modifies cups.service not to use cups.socket any longer). I’m currently using last option (with client and CUPS server).

6

Disabling cups.socket (and rebooting) did not help.

All of the printers worked under 13.1 until a recent update. I don’t
print often so I’m not sure exactly which update caused the problem.
I just noticed it yesterday.

I don’t have much time to trouble shoot, so simply restarting cupsd.service
whenever I (very seldom) restart the machines is a acceptable workaround.

7

No, you don’t just disable cups.socket as cups.service currently relies on it. The update from the OBS repo modifies cups.service and socket-activation is no longer used.

All of the printers worked under 13.1 until a recent update. I don’t
print often so I’m not sure exactly which update caused the problem.
I just noticed it yesterday.

It’s all covered in the thread I linked to and the corresponding bug rpeort.

I don’t have much time to trouble shoot, so simply restarting cupsd.service
whenever I (very seldom) restart the machines is a acceptable workaround.

That workaround may be okay for you, but not for those relying on printing in network environments, including CUPS servers.

8

I’m not discouraging others from using the OBS version.

For me, the manual workaround is no problem. I reboot maybe once a month.

Once an official fix is in the standard Update repos I’ll pick it up.

If I install from OBS then I have to keep monitoring when an official fix
is released so I can remove the OBS version and get the official version.
It’s a personal thing, but I don’t usually use any OBS repos unless it is
to resolve a system crash issue.

Thanks for the info.

9

Whatever works for you. :slight_smile:

10

You could also create a small script containing the command and have it automatically run at login.

First, write the script and place it where you have execute permissions (/usr/bin, for example).

To have it run at login:

Configure Desktop => Startup and Shutdown

Add Script

Now when you login, it is done for you.

11

That’s what systemd is for, but the socket activation was not working properly. However cups.service can be adjusted like so (with cups.service, cups.path disabled)

# cat /usr/lib/systemd/system/cups.service
[Unit]
Description=CUPS Printing Service
After=network.target

[Service]
ExecStart=/usr/sbin/cupsd -f

[Install]
WantedBy=multi-user.target
12

The following solution worked on my laptop for now:


systemctl disable cups.socket
systemctl stop cups.socket
systemctl restart cups.service

Which was taken from the thread that I had linked to in my initial post, and also by deano_ferrari in Post #5. I was just unsure whether this could mess up my system once the issue is fixed in a future update.

Thanks for the helping and clarifying responses! I really needed to fix this issue for my wife’s laptop, as she was not too pleased to enter a “cryptic” command every time she booted the laptop (which is about daily, since suspend is unreliable on that machine).
:wink:

13

**UPDATE: The above does not work for me.
**:frowning:

It only fixes one symptom of the original problem: the print dialog had an empty list of printers.

After the three commands above and rebooting, the print dialog now shows the correct printers available at the actual place, but it was only today that I actually wanted to print something - and it did not work again, until issuing “systemctl start cups”. I had only checked whether the list of printers was empty or not.

So I will try the other way using the OBS repository.

14

That’s what I ultimately did too. However, before that I had simply modified cups.socket similar to that suggested by this ArchWiki page

https://wiki.archlinux.org/index.php/CUPS#CUPS.27_systemd_service_does_not_start_even_though_it.27s_enabled

Both methods worked for me (with client and CUPS server machines).

15

For me worked Yast -> Printers ->
and get question “restarting cups” answer: “yes”

16

Thanks guys.

I just did a fresh install of openSUSE 13.1 on my wife’s computer and ran the updates/patches. When I went to set up her printer, there was a problem. Our home network/router plugs into an HP Jetdirect 300x (cups-backends needed) which plugs into our “networked” HP 6L printer, which was not working. My computer, running the same OS had no problems seeing the networked printer. I discovers as you did that cupsd was not starting during boot on my wife’s computer. Comparing the cups installed on our two computers I down graded her python-cupshelper to 1.4.2-2.4.1 so it matched mine. Cupsd still failed to start at boot.

Following your link, I added http://download.opensuse.org/repositories/Printing/openSUSE_13.1/ which was named Printer, to my repositories. (Yast)

Replacing using (Yast):

CUPS 1.5.4-12.13.1-x86_64 from opensSUSE-13.1-Update with 1.5.4-156.1-x86_64 from Printer

cups-backends 1.0-275.1.2-x86_64 ** with** 1.1-287.1-x86_64 from Printer

cups-client 1.5.4-12.13.1-x86_64 ** with** 1.5.4-156.1-x86_64 from Printer

cups-filters-foomatic-rip 1.0.58-35.1-x86_64 from Printer (added)

cups-filters-ghostscripts 1.0.58-35.1-x86_64 from Printer (added)

cups-libs1.5.4-12.13.1-x86_64 **with ** 1.5.4-156.1-x86_64 from Printer

cups-libs-32bit 1.5.4-12.13.1-x86_64 with 1.5.4-156.1-x86_64 from Printer

cups-pk-helper 0.2.5-2.1.3-x86_64 from opensSUSE-13.1-Update (kept)

gutenprint 5.2.9-5.1.3-x86_64 ** with** 5.2.10-46.1-x86_64 from Printer

python-cups 1.9.63-2.1.2-x86_64 from opensSUSE-13.1-Oss (kept)

python-cupshelpers 1.4.2-2.4.1 from opensSUSE-13.1-Update (kept)
(NOTE: python-cupshelpers downgraded prior to adding the Printer repo a newer version may work)

Have restarted my wife’s computer 3 times and cupsd is running. Now, localhost:361 opens CUPS and is ready to go. I am using socket with the IP address for our jetdirect 300x within CUPS.

Hopefully, this helps the next guy solve their printer issue a little quicker & perhaps makes thing a little more clear

17

Great!

Thanks for coming back with your solutions, I am bookmarking it for future reference.