We have a central cups print server (and one client offering a queue for a not network-connected printer) and about 50 identically configured clients running a current stable using it to print. On one specific client sometimes all printer queues stop working, giving the error message 'No destination host name supplied by cups-browsed for printer "name of the queue", is cups-browsed running?'.
Restarting the cups and cups-browsed services does not fix the behaviour; most of the times a reboot does, but not always.

Comparing the two browsed debug logs of the affected and and unaffected client I notice after printing (or trying to print) a test page, that the affected one is missing the lines, showing that the cups server contacted it. I'll attach the excerpt of the cups debug log showing the last connection attempts (of forty before cups gives up) below.

Changes to queues on the server get communicated through to cups by cups-browsed so communication in that direction seems to be working.

Both cups and cups-browsed on the client are currently running with the debug logs enabled, so if you need any more info I'll hopefully be able to provide it.

Probably just a coincidence but I'll mention it: The user of the affected client is the only one of ours that's running KDE as desktop.

Hello,

I discovered the same problem on my computer today and found out that it
is NO coincidence that the problem occurs on the KDE desktop.

After several unsuccessful attempts of getting it to work under KDE by
stopping cups and cups-browsed, editing configuration files, deleting
all files from /var/cache/cups and starting daemons again, I read your
post, then logged out of KDE, re-logged in with MATE, did the same as
before, except from editing configuration, and then, printing was
successful. I logged out from MATE, re-logged in under KDE and then,
printing did also work with KDE. Another daemon restart after deleting
cache files, error occurred again. Logged out, in again with KDE,
printing worked.

Beside the fact that printing worked immediately with another desktop
environment, but only with problems in KDE, I noticed another
difference: In MATE, files
/var/cache/cups/cups-browsed-options-´<printer> were created soon after
the printer information broadcast messages had been received, while in
KDE these files were created not before cups-browsed was stopped.

Regards
   Christoph

about this issue and had the same issue on my system. I would NEVER have
come to the conclusion that the desktop environment in use plays a role
in this issue which presents itself as rooted deeply between system
daemons and network issues.

The absolutely inadequate debug logging of the software in question has
not made it any easier to debug this issue.

That being said, my system prints again.

What did not help:
Activate KDE screen saver, start additional session, log in with the
same account with lxqt, try printing from there (didn't work, same
error).

What helped:
Log out of KDE, start new session with same account with lxqt, try
printing from there (worked), log out of lxqrt, log into KDE with the
smae account (worked).

This is one of the most mysterious and astonishing issuest hat I have
encountered in my lifetime. Kudos for nailing this down to KDE.

Greetings
Marc

about this issue and had the same issue on my system. I would NEVER have
come to the conclusion that the desktop environment in use plays a role
in this issue which presents itself as rooted deeply between system
daemons and network issues.

The absolutely inadequate debug logging of the software in question has
not made it any easier to debug this issue.

That being said, my system prints again.

What did not help:
Activate KDE screen saver, start additional session, log in with the
same account with lxqt, try printing from there (didn't work, same
error).

What helped:
Log out of KDE, start new session with same account with lxqt, try
printing from there (worked), log out of lxqrt, log into KDE with the
smae account (worked).

This is one of the most mysterious and astonishing issuest hat I have
encountered in my lifetime. Kudos for nailing this down to KDE.

Greetings
Marc

Thank you for your reports, Jens, christoph and Marc. For the avoidance
of doubt - I am not a cups-browsed maintainer.

It is unlikely to be a DE issue. I came across the behaviour today while
working in a non-KDE environment and printing from LibreOffice and with
lp.

Only Jens provides the cups version being used and modifications to
cups-browsed.conf made. For me, its cups v2.2.8 and having "driverless"
for the CreateIPPPrinterQueues directive as the only change. On the
surface, we are using different printing systems. I am only inclined to
conduct tests on unstable. "BrowseRemoteProtocols cups" doesn't motivate
me.

Has anyone managed consistently to reproduce the reported behaviour? I
haven't yet formulated a plan of attack to do so.

KDE? Maybe, maybe not. Perhaps the "No destination host name supplied..."
message has three different causes?

Regards,

Brian.

Thank you for your reports, Jens, christoph and Marc. For the avoidance
of doubt - I am not a cups-browsed maintainer.

It is unlikely to be a DE issue. I came across the behaviour today while
working in a non-KDE environment and printing from LibreOffice and with
lp.

Only Jens provides the cups version being used and modifications to
cups-browsed.conf made. For me, its cups v2.2.8 and having "driverless"
for the CreateIPPPrinterQueues directive as the only change. On the
surface, we are using different printing systems. I am only inclined to
conduct tests on unstable. "BrowseRemoteProtocols cups" doesn't motivate
me.

Has anyone managed consistently to reproduce the reported behaviour? I
haven't yet formulated a plan of attack to do so.

KDE? Maybe, maybe not. Perhaps the "No destination host name supplied..."
message has three different causes?

Regards,

Brian.

Should have said four. I brought my problem on myself by forgetting I
had disabled the queue I was printing to. :(

Should have said four. I brought my problem on myself by forgetting I
had disabled the queue I was printing to. :(

Dear Maintainer,

from debian10 (installed with DVD1), I have performed a distribution
upgrade to "bullseye" using the command upgrade followed by dist-upgrade.
Switching on my "HP Officejet Pro 8610" printer (time 14:03:00), the
system is able to identify it:

"The HP printer was detect automatically by the system:

Driver:?????? Officejet Pro 8610 - IPP Everywhere (color, 2-sided printing)
Connection:?????? implicitclass://HP_Officejet_Pro_8610_8C125D_/
Defaults:?????? job-sheets=none, none media=iso_a4_210x297mm
sides=two-sided-long-edge"

When I open cups web server and I try to print test page (time 14:07:15)
the printer is not able to complete the job (always active).

I have deleted the job and reprinted test page but I have got the
following error:

"pending since
Friday 25 oct 2019, 14:43:02
"No destination host name supplied by cups-browsed for printer
"HP_Officejet_Pro_8610_8C125D_", is cups-browsed running?"

In attachment cups error log and journalctl output

Thanks very much
Loris

PS: same subject as closed report bug #939316