[SOLVED] CUPS localhost:631 no longer works

mark_alfred · 10-03-2016, 09:08 PM

It continued to work after rebooting. However, if the usb printer cord was disconnected and then reconnected, it subsequently failed to work after unless I restarted cups via the command "sudo systemctl restart cups". I don't know if that was the case before or not. But, it seems to be the case now.

Hmm. Perhaps that solves this thread. I'm going to wait for a bit before I mark it solved though. But thanks for your help ferrari. Much appreciated.

ferrari · 10-03-2016, 09:49 PM

Quote:

It continued to work after rebooting. However, if the usb printer cord was disconnected and then reconnected, it subsequently failed to work after unless I restarted cups via the command "sudo systemctl restart cups". I don't know if that was the case before or not. But, it seems to be the case now.

This might depend on whether systemd socket activation is in use. We can investigate this further if required.

Quote:

Hmm. Perhaps that solves this thread. I'm going to wait for a bit before I mark it solved though. But thanks for your help ferrari. Much appreciated.

Glad to have been of assistance, even if only to steer you around some of the underlying CUPS configuration directives and useful commands.

BTW, the netstat command needs to be run with sudo to see the root-owned process.

mark_alfred · 10-05-2016, 06:56 PM

Code:

mark@mark-N150-N210-N220:~$ sudo netstat -tupln|grep 631
[sudo] password for mark: 
udp        0      0 0.0.0.0:631             0.0.0.0:*                           26653/cups-browsed

The localhost currently isn't working, perhaps because my printer is turned off. I'd likely have to either reboot my computer with the printer on for it to work or restart cups.

ETA:

After restarting cups and closing and then reopening the browser, cups does work. Here's the result of the command above now:

Code:

mark@mark-N150-N210-N220:~$ sudo netstat -tupln|grep 631
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      22390/cupsd     
tcp6       0      0 ::1:631                 :::*                    LISTEN      22390/cupsd     
udp        0      0 0.0.0.0:631             0.0.0.0:*                           22391/cups-browsed
mark@mark-N150-N210-N220:~$

I don't remember this changeable behaviour previously with the CUPS browser admin function, but perhaps I generally kept both my computer and printer on (I used to run a web server, so the computer was always on anyway). Oh well, regardless, at least now I know how to get the browser CUPS admin tool working again. So, another solved.

ferrari · 10-05-2016, 09:17 PM

Like I said previously, it's likely systemd socket activation at play. If so, it
can be configured to disable that feature and leave cupsd running permanently from boot
if desired. It can be explored further if you like.

JimKyle · 10-06-2016, 10:18 AM

Quote:

Originally Posted by ferrari

Like I said previously, it's likely systemd socket activation at play. If so, it
can be configured to disable that feature and leave cupsd running permanently from boot
if desired. It can be explored further if you like.

While this isn't my thread and I don't want to hijack it, I have definitely noticed a difference in network handling between 14.04 and 16.04, which appears to be due to the increased systemd presence in the newer version, so I hope you do explore the socket activation feature further!

What I've experienced are "network unreachable" and "connection refused" situations, in cases that previously worked flawlessly. At the moment all seems well, but would definitely like to know more about what systemd changed about my networking.

ferrari · 10-06-2016, 03:49 PM

This bug report describes and discusses the behaviour...
https://bugs.launchpad.net/ubuntu/+s...s/+bug/1598300

CUPS is using socket activation via the systemd cups.socket service. Observe that with...

Code:

sudo systemctl status cups.socket

and the unit file /lib/systemd/system/cups.socket is configured to listen to the the CUPS socket only

Code:

ListenStream=/var/run/cups/cups.sock

but not to port 631 activity. That is apparently deliberate (potential security issue), but can be implemented by adding

Code:

ListenStream=631

to the unit file. Once the unit file is reloaded with

Code:

sudo systemctl daemon-reload

it will take effect.

mark_alfred · 10-06-2016, 04:15 PM

Thanks for the information. I'll probably just leave it as is. At least now I know what's up with it and how to restart it if need be.

ferrari · 10-06-2016, 05:33 PM

It's interesting to note comment #19 in the bug report where the user reports

Quote:

No. Seems to be the option "-l" which causes systemd to shutdown cupsd and to restart if a print job is available. For applications with pre-checks for available printers or given printer names (for instance with java javax.print.PrintServiceLookup) or with CUPS web Interface on demand this does not work. I changed the option "-l" to "-f" in /lib/systemd/system/cups.service.

For reference, I'm using openSUSE Leap, and cups.service contains

Code:

ExecStart=/usr/sbin/cupsd -f

with the result being that cupsd is started at boot and remains active, and socket activation is not in use (ie cups.socket, cups.path are not present)

vanzandtj · 11-18-2017, 08:10 AM

Quote:

Originally Posted by ferrari

Is the following entry is present?

Code:

Listen localhost:631

This turned out to be my problem. Thanks!

I'm concerned, though. I have been running CUPS for years, and certainly never changed this configuration. It seems odd to disable the best-documented way to administer the printers.