Cannot access CUPS server after update

Addanc · January 23, 2014, 10:09pm

Accepted an update to CUPS; zypp/history log entries:

2014-01-22 18:47:43|install|cups-libs|1.5.4-12.4.1|x86_64||repo-update|3a389ae992b5d36c556b8d71fe0de451f68a7b0be4bfc8d0ecf9d7e2819fff51|
2014-01-22 18:47:44|install|cups-libs-32bit|1.5.4-12.4.1|x86_64||repo-update|ead1239900ad5bede1da09fd49f3c1ecdc83ae0feb9afcbb1aaee2e7d5fc3987|
2014-01-22 18:47:44|install|cups-client|1.5.4-12.4.1|x86_64||repo-update|71c183d3c5d3360986328d2a344c07879dd5f8a6d390eec3e2506e31e28bb537|

Today 23/01 I cannot see my CUPS server from any of my openSUSE boxes; more precisely none of my apps (KDE desktop) present my CUPS server printer. Problem isn’t the print server since I can still access it from a Windows box. Here is a small snapshot of the cups/error_log:

E [22/Jan/2014:18:25:14 +0000] Browsing=1
E [22/Jan/2014:18:25:15 +0000] BrowseLocalProtocols=0
E [22/Jan/2014:18:25:15 +0000] BrowseRemoteProtocols=1
E [22/Jan/2014:18:25:15 +0000] BROWSE_CUPS=1
E [22/Jan/2014:18:25:15 +0000] Unable to bind socket for address [v1.::1]:631 - Address already in use.
E [22/Jan/2014:20:55:16 +0000] update_polling: all polling processes have exited!
E [23/Jan/2014:17:34:34 +0000] Browsing=1
E [23/Jan/2014:17:34:34 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:17:34:34 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:17:34:34 +0000] BROWSE_CUPS=1
E [23/Jan/2014:17:34:34 +0000] Browsing=1
E [23/Jan/2014:17:34:34 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:17:34:34 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:17:34:34 +0000] BROWSE_CUPS=1
E [23/Jan/2014:18:32:34 +0000] [cups-polld yggdrasil:631] CUPS-Get-Printers failed: Success
E [23/Jan/2014:18:36:19 +0000] Browsing=1
E [23/Jan/2014:18:36:19 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:18:36:19 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:18:36:19 +0000] BROWSE_CUPS=1
E [23/Jan/2014:18:36:19 +0000] Browsing=1
E [23/Jan/2014:18:36:19 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:18:36:19 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:18:36:19 +0000] BROWSE_CUPS=1
E [23/Jan/2014:18:37:20 +0000] [cups-polld yggdrasil:631] CUPS-Get-Printers failed: Success
E [23/Jan/2014:18:48:23 +0000] Browsing=1
E [23/Jan/2014:18:48:23 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:18:48:23 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:18:48:23 +0000] BROWSE_CUPS=1
E [23/Jan/2014:18:48:23 +0000] Browsing=1
E [23/Jan/2014:18:48:23 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:18:48:23 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:18:48:23 +0000] BROWSE_CUPS=1
E [23/Jan/2014:18:56:37 +0000] Browsing=1
E [23/Jan/2014:18:56:37 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:18:56:37 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:18:56:37 +0000] BROWSE_CUPS=1
E [23/Jan/2014:18:56:37 +0000] Browsing=1
E [23/Jan/2014:18:56:37 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:18:56:37 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:18:56:37 +0000] BROWSE_CUPS=1
E [23/Jan/2014:20:05:26 +0000] Browsing=1
E [23/Jan/2014:20:05:26 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:20:05:26 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:20:05:26 +0000] BROWSE_CUPS=1
E [23/Jan/2014:20:05:26 +0000] Browsing=1
E [23/Jan/2014:20:05:26 +0000] BrowseLocalProtocols=0
E [23/Jan/2014:20:05:26 +0000] BrowseRemoteProtocols=1
E [23/Jan/2014:20:05:26 +0000] BROWSE_CUPS=1
E [23/Jan/2014:20:37:45 +0000] [cups-polld yggdrasil:631] CUPS-Get-Printers failed: Connection reset by peer

I have tried switching off the firewall temporarily and this has had no affect. I would appreciate any suggestions for debugging the problem.

hcvv · January 24, 2014, 11:50am

I nowhere could find which version of openSUSE this is happening on. Did I miss something or didn’t you provide that information?

gian2linux · January 24, 2014, 1:05pm

Hi, I can’t see my CUPS server too. I’we patched my OS 12.3 (now it’s up-to-date). Today’s log is quite different (and it seem be ok) :’(

E [24/Jan/2014:09:00:38 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:09:00:38 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:09:00:38 +0100] BROWSE_CUPS=1
E [24/Jan/2014:09:00:38 +0100] Browsing=1
E [24/Jan/2014:09:00:38 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:09:00:38 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:09:00:38 +0100] BROWSE_CUPS=1
E [24/Jan/2014:11:11:50 +0100] Browsing=1
E [24/Jan/2014:11:11:50 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:11:11:50 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:11:11:50 +0100] BROWSE_CUPS=1
E [24/Jan/2014:11:11:50 +0100] Browsing=1
E [24/Jan/2014:11:11:50 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:11:11:50 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:11:11:50 +0100] BROWSE_CUPS=1
E [24/Jan/2014:11:17:05 +0100] [cups-driverd] Bad driver information file “/usr/share/cups/drv/sample.drv”!
E [24/Jan/2014:11:18:38 +0100] Browsing=1
E [24/Jan/2014:11:18:38 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:11:18:38 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:11:18:38 +0100] BROWSE_CUPS=1
E [24/Jan/2014:11:18:38 +0100] Browsing=1
E [24/Jan/2014:11:18:38 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:11:18:38 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:11:18:38 +0100] BROWSE_CUPS=1
E [24/Jan/2014:11:23:51 +0100] Browsing=0
E [24/Jan/2014:11:23:51 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:11:23:51 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:11:23:51 +0100] BROWSE_CUPS=1
E [24/Jan/2014:11:23:51 +0100] systemd_checkin: Socket not of the right type
E [24/Jan/2014:11:23:51 +0100] Browsing=0
E [24/Jan/2014:11:23:51 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:11:23:51 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:11:23:51 +0100] BROWSE_CUPS=1
E [24/Jan/2014:11:23:51 +0100] systemd_checkin: Socket not of the right type
E [24/Jan/2014:11:24:08 +0100] Browsing=1
E [24/Jan/2014:11:24:08 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:11:24:08 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:11:24:08 +0100] BROWSE_CUPS=1
E [24/Jan/2014:11:24:08 +0100] Browsing=1
E [24/Jan/2014:11:24:08 +0100] BrowseLocalProtocols=0
E [24/Jan/2014:11:24:08 +0100] BrowseRemoteProtocols=1
E [24/Jan/2014:11:24:08 +0100] BROWSE_CUPS=1

wolfi323 · January 24, 2014, 1:26pm

Well, the only change in the latest update was that cups is now only listening on localhost by default.
See https://bugzilla.novell.com/show_bug.cgi?id=857372

If you want cups to listen to requests from the outside, you may have to configure that in /etc/cups/cupsd.conf .

And you also may have to explicitely enable cups.service. By default it is socket-activated, i.e. it is only started if a request is coming, but I’m not sure if that works with requests from other hosts.

hcvv · January 24, 2014, 2:13pm

Sorry that I am a bit retarded iin understanding this. But are you saying that after many years that you clicked in your CUPS managing tool that you allowed other systems to use your system’s printers ( they call it advertise IIRC), this will not work any more. Not even on systems were it is already configured?

hcvv · January 24, 2014, 2:19pm

Using YOL, I indeed see a cups update which mentions:

Hardening:

cups-0002-systemd-listen-only-on-localhost-for-socket-activation.patch
fixes the systemd cups.socket file so that systemd listens only on localhost (bnc#857372).

Will this indeed switch off all fuinctioining CUPS servers?

Then we can await much, much more threads here above the two I think I detected already.

And what should the general advice be here. Not the “you may have to configure that in /etc/cups/cupsd.conf .” Most people use YaST and/or goto localhosts:631 to manage CUPS. My idea is that we have to find how to cure this in a user friendly way and maybe make a sticky of it.

wolfi323 · January 24, 2014, 2:30pm

I’m not saying that. I just wanted to point out what the update has changed and possible causes for the problems. (the socket-activation is not new, that was introduced with the change to systemd. I just mentioned it for completeness)

If you explicitely configured your CUPS to listen on the network, it should continue to work I think. AFAICS that update only changed the default config.
If you relied on it to do that by default, you would have to change the config of course.

But apparently the update did cause a problem with the socket.activation: (https://bugzilla.novell.com/show_bug.cgi?id=857372#c46)

hmm … well, i just tested your setup and cups.socket works very bad … i’dvote for kicking it out … if you have disabled cups.socket and you just change
cups.conf to listen wherever you need (eg Listen variable) and start the
service without socket it works expectably

That’s why I suggested to enable cups.service explicitely (and apparently you should disable cups.socket). Then cups should be started unconditionally on boot, not only when a request arrives at the socket.

I don’t really know anything about that though. I just read the bug report.

Maybe have a look at https://bugzilla.novell.com/show_bug.cgi?id=857372#c41 and the following comments.

wolfi323 · January 24, 2014, 2:34pm

I don’t know.
Better ask in the bugreport.

hcvv · January 24, 2014, 2:44pm

I now understand you better, thanks.

Having installed 13.1 anew about a weel so (replacing 12.3), I am almost sure I explicitly clicked in CUPS to advertise itself. Thusthis should hold over the patch.A

And I went to that bug report. But I did not read it all, beyond my understanding.

That’s why I suggested to enable cups.service explicitely (and apparently you should disable cups.socket). Then cups should be started unconditionally on boot, not only when a request arrives at the socket.

That would need a more practical instruction for a lot of our audience.

In any case, athe the moment, thus before the patch I have:

boven:~ # netstat -tulp | grep ipp
tcp        0      0 *:ipp                   *:*                     LISTEN      496/cupsd           
tcp        0      0 *:ipp                   *:*                     LISTEN      1/init              
udp        0      0 *:ipp                   *:*                                 1/init              
boven:~ #

T
My interpretations is that cupsd is running.

robin_listas · January 24, 2014, 2:48pm

On 2014-01-24 13:06, gian2linux wrote:
>
> Hi, I can’t see my CUPS server too. I’we patched my OS 12.3 (now it’s
> up-to-date). Today’s log is quite different (and it seem be ok) :’(

I see at least a similar report on the mail list.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

wolfi323 · January 24, 2014, 3:18pm

Well, I did not read (or understand) every aspect of it either. And it doesn’t affect me anyway.
But those who are affected might get the information they need there.

That would need a more practical instruction for a lot of our audience.

sudo systemctl disable cups.socket
sudo systemctl enable cups.service

But again, personally I don’t know if this is necessary.

In any case, athe the moment, thus before the patch I have:

boven:~ # netstat -tulp | grep ipp
tcp        0      0 *:ipp                   *:*                     LISTEN      496/cupsd           
tcp        0      0 *:ipp                   *:*                     LISTEN      1/init              
udp        0      0 *:ipp                   *:*                                 1/init              
boven:~ #

T
My interpretations is that cupsd is running.

From what I can tell this should be ok.

hcvv · January 24, 2014, 5:06pm

I installed the patch (via YOU). The result:

boven:~ # netstat -tulp | grep ipp
tcp        0      0 *:ipp                   *:*                     LISTEN      8902/cupsd          
tcp        0      0 *:ipp                   *:*                     LISTEN      8902/cupsd          
udp        0      0 *:ipp                   *:*                                 8902/cupsd          
boven:~ #

A bit different from before (and cupsd is apperently restarted, different PID).
But I can still print from the other PC.

Tomorrow we will know if this survives a reboot of the CUPS server.

caf4926 · January 24, 2014, 5:23pm

Something is messed up
I just don’t have time to dig in to it

Addanc · January 24, 2014, 8:37pm

openSUSE 13.1 x86-64

wolfi323 · January 24, 2014, 8:43pm

hcvv:

I installed the patch (via YOU). The result:
boven:~ # netstat -tulp | grep ipp
tcp        0      0 *:ipp                   *:*                     LISTEN      8902/cupsd          
tcp        0      0 *:ipp                   *:*                     LISTEN      8902/cupsd          
udp        0      0 *:ipp                   *:*                                 8902/cupsd          
boven:~ #
A bit different from before (and cupsd is apperently restarted, different PID).
But I can still print from the other PC.

So apparently systemd (i.e. “init”) isn’t listening anymore.
It still works because cupsd istself runs and is listening.

If you have the cups.service enabled, cupsd will be started unconditionally at boot and will listen again, so it will still work.
If cups.service is not enabled (i.e. you rely on the socket-activation), printing will not work from a different PC because cupsd is not running and nobody is listening on port 631. (systemd will only listen on localhost:631 and start cupsd when a request comes)

wolfi323 · January 24, 2014, 8:45pm

Try to start cups.service manually with either “sudo systemctl start cups.service” or YaST->System->Services Manager.
Does printing work then?

If yes enable it to make it work persistently with “sudo systemctl enable cups.service” or YaST->System->Services Manager.

If not, there’s something wrong with your cupsd configuration I’d say.

Addanc · January 24, 2014, 8:50pm

In my case its the CUPS clients running on SUSE 13.1 boxes; the CUPS server running on RaspberryPI/Debian is fine; I can print from a WIndows box without a problem.

wolfi323 · January 24, 2014, 9:03pm

Sorry, the others here talked about the server, that confused me.

For the client the update shouldn’t have changed anything.
But you could try to explicitely start cups.service (i.e. cupsd) on the client anyway to see if it makes a difference.

Addanc · January 24, 2014, 9:42pm

Already had cups and cupsd enabled and active.

wolfi323 · January 24, 2014, 10:54pm

Hm, is your printer listed in cups’ configuration page?
(type http://localhost:631/ into a web browser on the client)

Is “Show shared printers from other systems” enabled there? (“Management” tab)
Or have you explicitely added it? If not, maybe try that. (click on “Add printer”)

As said, the update should only affect a cups server, not client. Might be coincidence that it doesn´t work for you since the update.

You could switch those packages back to the earlier versions though to verify (in the case of the update repo, older versions do not disappear but stay in the repo, and the version in the standard OSS repo is available as well anyway). Just select them in YaST->Software Management and click on “Versions” below the package list.