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.
# 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.
Hello there,
If you type systemctl stop cups – you will get a message:
Warning: Stopping cups.service, but it can still be activated by:
cups.path
cups.socket
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 ….
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