-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
detected remote printer vanishs with "No destination host name supplied by cups-browsed" on printing #97
Comments
What I need from you is a log file from cups-browsed. To get one, please edit
Restart cups-browsed and then wait until the (non-working) print queues appear. Then attach the file |
I tested printing and started a job from machine a (rzha059) to b (rzhd040)."a" here stands for PC which means machine and "d" within the name means printer (German "Drucker" and usb-connected) on a remote machine (PC) rzha040. Following message might be of importance among many lines of cups-browsed_log: |
Can you please attach the complete log file(s) to this bug report? I need to see what happens until it comes to the error. Thanks. |
Hi, Btw. Keep an eye on a small scribal error "curremt" instead of "current" |
Why did you close this issue? |
I didn't want to close this issue, try to reopen.. |
I must add that after receiving this error after lpstat -d and having sent the print-job, cups-browsed didn't collapse. It was still working but seems having lost its job Id. Found it in utils/cups-browsed.c |
Subscribing because I see exactly the same behavior on multiple machines since the upgrade from Ubuntu 16.04 to Ubuntu 18.04. Cups version on print server (Debian 9) is 2.2.1-8, on client is 2.2.7-1ubuntu2.3. I tried changing multiple directives like increasing Http(Local|Remote)Timeout in cups-browsed.conf, but with no permanent success. cups-browsed creates an implicit class for each printer, but stops the printer with the quoted error message after a few seconds. Since it does work from time to time this looks like a race condition to me. |
For our administration it's a serious issue because if you don't use "LocalQueueNamingRemoteCUPS RemoteName" output is very long and confusing. Our customers might spray prints all over. This can't be tolerated and should be fixed. Only few problems occured with cups 1.7.5 (OpenSuSE 42.2/3 and SLES12). |
cups-browsed is not able to determine the ID of your job in order to give the CUPS backend instructions to which server to pass on the job.
and post the output here. |
A possible workaround (do it only after you have followed all my instructions in my previous comment):
by
and restart cups-browsed. |
Here are the wanted files. Please note that cupsd.conf and cups-browsed.conf are autogenerated by a function called edit_conf and based on corporate Metafiles to enforce common behaviour cups-browsed.conf_rzha040.txt Unfortunately detection of cups2.2-clients seems not to work stable compared to 1.7.5 PCs. Does BrowsePoll still work with dnssd? |
Did you also do the test with " |
Unfortunatety we have Printservers using cups 1.3.5 (SLES-11). We are going to exchange them in a couple of months. I'm not quite shure, if our cups 1.7.5 clients (OpenSuse 42.2/3) use old fashioned cups browsings method. if necessary, I'll post config files her. I'll try to apply you proposals.. |
If the CUPS 1.3.5 machines are only servers and not clients you will not need " |
My first trial with your proposals worked half: the error-message didn't occur anymore, but printing vanished in the darkness without reaching a cups 2.2 client (rc=0). Now I've removed all cups protocols with only little changes: |
Update: switching "BrowseProtocols" to "CUPS" in cups-browsed.conf. Advertising works with all computers (1.7.5 and 2.2) and printing from cups 1.7.5 (passive) clients to 2.2 (active) computers with a local printer. But printing 2.2 (passive) to 2.2 (with local printers) is only simulated, remote print-queue is visible, and lp returns with RC=0 but prints vanish in the dark never reaching the target. That means CUPS-protocol is half deprecated. Incoming queues are visible but not working because cups-browsed doesn't sent Print tasks via CUPS-protocol. |
New results: DNSSD-packets of 2.2 service are obviously spread in the local network but a bug in OpenSuSE 15.0 doesn't let them get reveived. This issue seems to be fixed in Tumbleweed: |
Does this mean that I can close this issue now? |
Built new version of cups-filters (including dependent qpdf) in OpenSuSE factory. Testing.. |
I've installed the cups-filter package and dependencies from Ubuntu Disco (1.22.1) but still get ""No destination host name supplied by cups-browsed for printer "printername", is cups-browsed running?" when trying to print a test file. BrowseRemoteProtocols and BrowsePoll don't make a difference. Logs and current config: |
@Cybso, could you attach a cups-browsed_log after having sent a print job which has failed? |
@tillkamppeter This is a log file after sending a failed print job. There are no new lines appended when cups fails to print the job. |
@Cybso, perhaps you have some D-Bus problem of your CUPS not sending notifications of the printer state changed. This way your problem seems to be different to the one of the OP. |
@tillkamppeter Do you have any hint for me where to look for debugging information? Basically this is a fresh Kubuntu 18.04 workstation, configured via Saltstack (but none of the saltstack rules touches any dbus configuration). I'll do a test with a clean unconfigured installation when I'm in the office at Saturday since I have to restore another workstation anyway. |
One approach is to try untouched Ubuntu configurations, without using Saltstack. You can also use virtual machines for that.
Then restart CUPS and cups-browsed and wait until all the queues are created. After that submit a print job. Wait until the error occurs again. |
Now you can also test with the cups-filters 1.22.2 release. |
Firstly, thank you for your effort.
works stable but queues now are displayed in the follwing mode:
This is not feasable because we normally configure computers without directly connected printers with the name of the remote queue so that the output of 'lpstat -v' lookes like this (legacy mode of cups <1.7.5).
IP-addresses in queue names will cause a lot of confusion and manual work during |
First, did you upgrade to cups-filters 1.22.2? Do jobs reliably print with that version?
together with
you get always the queue names of the form
even if you do not actually have multiple servers with the same queue name. |
These settings (in combination with "BrowseLocalProtocols cups" on the server) seems also to have solved my problem. However, I tried the whole weekend to reproduce this problem in virtual machine - without success. It seems to occur more frequently when the server is propagating multiple printers. In our normal configuration we have five printers (or pre-configured versions of the same printer). Thus, the problem almost always occurred in the VM. If I configured only one printer, the problem almost never occurs. This morning, however, I was told that the problem also occurred in production with the current setup with two printers, after which I tried the configuration of @reinilowsax - for the moment with success. So I'm not sure if this is really another problem. I've tested with Debian 9 and Ubuntu Server 18.04 as a server and with Ubuntu 18.04 and 18.10 as client. |
I'll do check this in the evening, I'm at work at the moment. |
failed in compiling it myself on OpenSuSE 15.0. (gcc11 not available on OpenSuSE). Maybe I need binary packages. For using OpenSuSE Build-Service you need to rebuild qpdf together with cups-filters. It would be appreciated, if cups-filters 1.22.2 could get availlable for OpenSuSE 15.1, because we would like migrate to it on 12.000 computers. |
I've applied the patch to the cups-filters-1.20.2 package in Ubuntu 18.04 (had to merge some parts manually) and until now remote printing seems to work, no matter how many printers I've configured on the server. May I ask what this patch changes? It's slightly hard to read since parts of the original code where moved into its own function. I will roll out the modified package to the production clients and see what happens. |
@Cybso, thank you for your feedback. |
@reinilowsax, unfortunately, I cannot help you with SUSE Linux integration, as I do not use SUSE Linux. |
@Cybso, could you attach your patch here, so that I can use it for a SRU (Stable Release Update) on Ubuntu? Thanks. |
Next trial: |
f0e1fc43dc5ec79a783cf2df82d9df827f3ccece-1.20.2-0ubuntu3.txt |
@reinilowsax, @Cybso has backported my patch to 1.20.2 and he has attached his backport here while I am writing this post. This could probably also work on the 1.20.3 of OpenSUSE 15.1. |
@Cybso, thank you very much. |
Thank you very much, trying to build a new package 1.22.x with your modifications and hoping the best for upcoming OpenSuSE-Release 15.1... |
With this configuration, the hangups didn't occur anymore:
I'll do more tests with slight modifications... |
Seems to work fine.. |
@reinilowsax, thank you very much. Then I will close this as fixed. |
Not sure I should revive this thread but I am experiencing this issue right now with cups-filter 1.25.11 on Ubuntu 19.10. Logs below as well as output from lpstat -o, however, lpstat result is for job 256 which was the same file printing and the same error as shown for job 253 below. error.log: cups-browsed_log: Wed Mar 11 10:56:14 2020 Full list of IPP attributes (get-printer-attributes) for printer with URI ipp://10.0.5.63:631/printers/Limeira_Euro_Etiqueta29mm: Logs: |
I have Ubuntu 20.04 with |
For anyone who has are still getting "No destination host name supplied by cups-browsed" in their logs and the job not getting printed:
|
Which version of avahi are you using? |
$ avahi-resolve --version
avahi-resolve 0.7 |
Might be the same problem on my side:
|
This ugly bug if fucking us up every few days! |
I think, this bug is fixed forever with cups-filters 1.28. Despite it has cause a lot of trouble in the past. |
Switching "LocalQueueNamingRemoteCUPS" to "RemoteName" in cups-browsed.conf, detected remote printers listed providing showing the remote queue name (exactly the name, the queue was set up on the remote machine) will break the local queue. The printer is listed unreachable:
"No destination host name supplied by cups-browsed for printer "queue-name>", is cups-browsed running?"
activating the queue and restarting all services (cups, cups-browsed) won't help. Switching
"LocalQueueNamingRemoteCUPS" to "DNS-SD" will make the queue accessible again. Printing works fine again. Accessing remote queues via original (short) queue-names is very helpfull to identify remote printers and will avoid confusion about these long remote queue names.
This bug stills exists in OpenSuSE Tumbleweed with the latest version of cups-filters:
tested with cups-filters-1.22.1-100.1. cups-filters.1.22.1-1.1
As our administration wants to switch to OpenSuSE 15.1 on 12.000 computers in a couple of months, a quick bugfix would be appreciated.
This bugreport was already filed here:
https://bugzilla.opensuse.org/show_bug.cgi?id=1128167
The text was updated successfully, but these errors were encountered: