systemd, CUPS, and /var/run/cups/cups.sock refusing connections

I was debugging a strange problem with a printer server running CUPS the other day. The web admin interface (which executes the script /usr/lib/cups/cgi-bin/admin.cgi via CGI) was returning a 500 “Internal Server Error”, while running lpadmin or lpstat would return Bad file descriptor. Using strace on the script locally on the server, it could be seen that the attempt to connect to the control socket /var/run/cups/cups.sock was failing with ECONNREFUSED. Huh? Seems like CUPS forgot about the socket, so issue service cups restart. Well, that didn’t fix it either.

To make a long story short, when running with systemd, the /lib/systemd/system/cups.socket control file causes systemd itself to own the socket, and to pass it to CUPS inetd-style when the CUPS process is created. Unfortunately, if that socket gets into a bad state, it will be impossible to communicate with the CUPS child process of systemd through the socket.

How to fix it?

# systemctl restart systemd.socket
# service cups restart

The socket will be refreshed and the newly working socket will then be passed to the CUPS child process when it is re-created.

2 Responses to “systemd, CUPS, and /var/run/cups/cups.sock refusing connections”

  1. Filipe says:

    Hello there,

    If you type systemctl stop cups – you will get a message:
    Warning: Stopping cups.service, but it can still be activated by:
    If you then type:
    systemctl stop cups.path and systemctl cups.socket they will stop. You can then issue the systemctl disable cups.service. This will stop cups 100%

    try to enable it:
    systemctl enable cups.service
    systemctl start cups.service
    systemctl start cups.path
    but when you issue the command:
    systemctl start cups.socket you will get:
    Job for cups.socket failed. See “systemctl status cups.socket” and “journalctl -xe” for details.
    systemctl status cups.socket
    ? cups.socket – CUPS Printing Service Sockets
    Loaded: loaded (/usr/lib/systemd/system/cups.socket; enabled; vendor preset: enabled)
    Active: inactive (dead)
    Listen: /var/run/cups/cups.sock (Stream)

    I can fix it by rebooting the system… but how to solve this without rebooting…?
    I learned that after a while, like 5 minutes or so, if you try to start the cups.socket service it works… really weird ….

  2. Vishwaa says:

    Even I faced the same issue and couldn’t restart cups.socket since Socket service cups.service already active, refusing.

    The solution is:Remember to Follow the order.

    systemctl stop cups.socket
    systemctl stop cups.path
    systemctl stop cups.service

    Wait for 3-5 minutes

    Now start the services:

    systemctl start cups.socket
    systemctl start cups.path
    systemctl start cups.service

    systemctl status cups.path cups.service cups.socket

Leave a Reply