-
Notifications
You must be signed in to change notification settings - Fork 4
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
No destination host name supplied by cups-browsed for printer #23
Comments
Got my printout after printing again, then manually running |
Note that cups-browsed skips paused printers when looking for the destination for a job, so if the destination printer of a cups-browsed-generated print queue is paused, cups-browsed does not find a destination and gives the error. So keep an eye that your printers are not paused/disabled when printing. Also somehow your So should we close this now as you are able to print again? |
But wasn't the printer originally paused because of this bug? And doesn't restarting cups-browserd unpause the printer? (I ask because I see the job getting retried and failing again in error_log after I do I've experienced the bug once before, in Ubuntu 21.04, with cups-filters 1.28.8. At the time the workaround mentioned in OpenPrinting/cups-filters#321 (restarting cups-browsed) sufficed. This time it didn't.
Yes, that was weird. I wish I made better notes of what exactly I did; I was sometimes testing by keeping a queued print job and seeing it be retried automatically when I restarted cups-browsed; at other times I deleted the job and printed the file again. The successful print was after I (1) restarted cups-browsed with debugging enabled, (2) saw an existing print job get retried with no success and scant logging from cups-browsed, (3) deleted the job, (4) printed the file again, then finally (5) ran cupsenable. The cups-browsed_log attached here was captured after step 2. After step 5 I have a lot of log entries of the successful handling of the job. I could attach the new log, but I'm not sure it's useful.
I don't mind closing the bug, but I have no confidence that it won't come back. I'm going to keep debug logging enabled so I can provide better logs if this happens again. |
I keep hitting a similar bug with Brother network printers on a local network. Printing is extremely unreliable due to it, and I'm not sure what makes it succeed (I generally try to restart cups, cups-browsed and the printer, sometimes to no avail). I'd be happy to provide more information or try debugging things. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990331 (I suspected app-armor at some point but I don't think it's the culprit anymore). |
One additional idea to try (you need to compile C code for that, also mainly for cases where printing sometimes works and sometimes not):
|
Today I cannot print again. Excerpts from log files in /var/log/cups:
10:35 is when I woke up the laptop in the office network, 14:27 is when I printed a job, 14:31 is when I ran
Same as last time: a CreateProfile error on printer discovery, a Bad value error whenever a job is being processed, and a No destination host name supplied error from cups-browsed. Now the interesting bit: Printer discovery at 10:35 shows up there. Print jobs at 14:27 or 14:31, however, do not. The only thing that appears are those repeated
messages. Does this provide any clues to anyone? I'm also attaching the logrotated cups-browsed_log.1, just in case there might be clues how cups-browsed got into this situation where it ignores jobs: cups-browsed_log.2.gz ends with
so I think older logrotated files aren't relevant.
|
Since I had to print, I did a Additional logs:
cups-browsed_log is too big for excerpts, so here's a full version: Curiously I see that it ends with the same
bit that I earlier assumed the service was shutting down, what with the "shutting down ..." and "main loop exited", but ps shows that the process is still running:
I just printed a test page and it came out fine, so no, that's a red herring. |
@mgedmin Could it be that you had 2 cups-browsed processes running? The log output of the shutdown sequence would be then from one and the process you have seen afterwards from the other. And while there were two cups-browsed processes running, competing somehow with each other you were not able to print and as soon as one got shut down you could print, controlled by the other. So check whether there is more than one cups-browsed running if you cannot print again. Do a |
I have the atop daemon running in the background, which records system snapshots (such as PIDs and command lines) every 10 minutes. Looking at the log file for Nov 29 and Nov 30, I see that only one cups-browsed process is running at one time, but the PID changes after each Looking at these cups-browsed restart timestamps, I think I got mixed up between terminal tabs and log files in my earlier comment -- there was no restart on Dec 1:
|
There are two different issues for the same bug, OpenPrinting/cups-filters#357 and #23. What is the difference between them, because I have not been able to find one. Maybe one should be closed and marked as duplicate of the other. I am running into the same issue on several machines running Ubuntu 20.04, I might be able to help out if any more information is needed. Is that the case, is there something to test out? |
@mgedmin Could you please enable CUPS debugging and attach all the log files here again after an unsuccessful print job? To enable CUPS debugging, run:
and then restart CUPS. |
@makuser If you are running into the same issue, could you attach your CUPS error_log and cups-browsed_log (with debugging enabled) here after handling an unsuccessful print job? Enable CUPS debugging as shown above. cups-browsed debugging can be enabled by editing
and then restarting cups-browsed. |
Perhaps the problem is caused by AppArmor settings. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990331 So look for messages containing |
Is there a way of testing whether cupsd can talk to cups-browsed and get a valid IP, without wasting paper? I've been delaying additional testing on this issue because I don't have anything I want to print (and I irrationally believe that printing would work if the only reason I did it was to reproduce a bug). The apparmor allegations have been mentioned before, in an earlier comment, and don't quite explain why the bug would be non-deterministic and go away after restarting/unpausing/retrying things without adjusting AppArmor profiles or enforcement rules... |
Kind of same issues here. Network HP Laserjet 1028 printer (behind a Raspberry Pi Zero); printer is often listed as disabled in It works sometimes; seems random to me (tried to identify some correlation with reboots but without success). To print I use my Android phone, it works perfectly from the phone. I'm aware this comment is no very helpful as it, but maybe can I give more information as it seems related to this bug. Ubuntu 22.04 LTS |
Hi, I went through a similar problem recently and fixed it. After an update (I'm assuming ubuntu was updated to 22.04.1, but I wasn't there - someone else updated it), my ubuntu briefly worked with my printer before stopping, and after attempting to set it up again (with the message
In the cupsd.conf file you uploaded, your /admin section looks like this - I think it's what mine looked like before I changed it:
The printer soon stopped working again (at one point, it stopped working with non-linux computers and had to be reconnected to our router) - this time with the error "cups-pki-invalid", which people found and solved here: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1973441 For steps on how to delete the outdated certificate: After all of this, my printer started working again without issues. I don't know that much about linux - I won't be able to help you further if this doesn't work for you or if you run into any problems. But I don't believe any of these instructions will harm your computer, and hopefully you at least get closer to diagnosing the problem. |
Thanks for sharing @MkTr ! I just tried this solution:
=> it didn't changed anything in my case :( BUT after deleting and re-adding printer in No idea if the previous steps (that you proposed) helped or not but I assume it does (I'm quite sure I already tried to delete and recreate shared printer). Note: all modifications have been made on the computer that sends data to printer, not my Raspberry Pi that runs CUPS server and is physically plugged to the printer. Thanks ! |
This ugly bug fucks up here every few days. Return to working Browsing methods fom cups 1.0, befor Apple bought cups and broke/destroyed the fantastic working linux network printing. |
I'm having this issue with two kde Neon computers. My Epson WF 7620 has worked fine for years, but a recent update caused these issues and I'm only now getting to try and work it out. No matter what I try (removing cups-browsed, re-adding it, stopping and starting it) I cannot get a test page to print, the printer always goes into pause, and when I restart it with the gui or command line, I get an extra page, but still no print. The log file looks like when I've done a bunch of systemctl restart cups-browsed, systemctl restart cups, or cupsenable EPSON_WF_7620_Series. Just for good testing I tried sudo cupsenable EPSON_WF_7620_Series, but that seems to have made things worse, the log having E [29/Apr/2023:18:14:19 +1000] [Client 4] Returning IPP client-error-bad-request for Create-Printer-Subscriptions (/) from localhost. and it still died. Any other thoughts? |
I have this problem on Debian 11 with GNOME desktop environment. Trying to print from an HP LaserJet Pro MFP printer. |
Same issue (fixed for now, see below) on Ubuntu 22.04.2 LTS; one minute after trying to print, I get:
Initially the printer was found automagically, and just worked, but not robustly. As others noted, it's a bit random. Every midnight, CUPS seems to roll the dice; if I'm lucky I can print that day, if I'm unlucky I cannot. (The timestamp of
The CUPS filters readme https://github.com/jianglei12138/cups-filters/blob/master/README provides "some info on how cups-browsed works internally", a lot of helpful documentation, in particular:
Sure enough my printer
The first command wrote a new |
Tried to print a page today after a looong break, got the
error again. Ubuntu 23.04, cups 2.4.2-3ubuntu2.5, cups-browsed 2.0~rc1-0ubuntu1.1. Tried restarting cups-browsed, tried pausing/unpausing the job in gnome-control-center, tried deleting the job and printing again through a different printer (same device, different queue that goes through our office's local server running CUPS exporting the print queues), the page got printed. No time for deep debugging again. I do have some kind of debug logging enabled in cups-browsed.conf from previous attempts, the relevant time range seems to be
after which I restarted cups-browsed. Full cups-browsed_log: cups-browsed_log.txt error_log has
|
Just wanted to chime in here, I'm experiencing the same on Debian 12. The bug seems to have been around for an absurdly long time (threads about it on StackOverflow from 2019!) and affects quite a good chunk of people. I personally solved it by just removing cups-browsed from my system completely, although it isn't exactly the nicest solution if you actually need it :P PS not caused by apparmor for me and appears to have been solved in OpenPrinting/cups-filters#148 but still nothing |
I have say that I had the same issue on Kubuntu (Ubuntu 23.10). Initially I was really happy - printer was auto-detected, and after day or two I started to have the same error. I didn't have time to investigate so I ended with removing cups-browsed and things started working as expected. Printer added and is printing. So not sure what is wrong but error is really making people frustrated especially when some quick print needs be done and .... it can't be done because of this error. |
I have found a solution for this, please try it out, current GIT master of cups-browsed (2.x, not cups-filters): 57d9351 As queues with I have also changed the behavior when a queue created by cups-browsed gets externally overwritten. Such queues only get released by cups-browsed and replaced by a differently named queue if the This way we will never have So please test ... |
Today I cannot print from my Ubuntu 20.10 laptop. The printer is detected, a print job gets created, stays active for 60 seconds, then goes into waiting. /var/log/cups/errorr_log has
at the time when the job is first created, then
Printing worked fine just a few days ago, with the same Ubuntu version and the same printers. I'm not sure what changed.
OpenPrinting/cups-filters#97 (comment) suggests creating an issue here.
cups-browsed is running. restarting cups-browsed doesn't make the problem go away.
1.28.10-2
Two, which is correct: the printer advertises itself over DNS-SD, and there's a local server (fridge.lan) with a CUPS queue for the same printer. Printing to either queue fails in (almost) the same way; the only difference is that only one of the two queues produces the "Bad value (0) for orientation-requested" error.
lpstat -v shows
(the USB printer is currently disconnected and is irrelevant to this bug report)
(I've made two changes to cups-browsed.conf, compared to stock ubuntu config: removed
cups
fromBrowseLocalProtocols
, and uncommentedDebugLogging file stderr
.)Also, here's /var/log/cups/cups-browsed_log after I enabled debug logging and restarted cups-browsed, then tried printing.
cups-browsed_log.txt
Other bug reports had questions about Avahi version, so
I can ping both fridge.local and cream.local, i.e. DNS-SD name resolution works fine on the system. (Besides, cups-browserd detects the printers fine, so it must be seeing mDNS packets).
I'm not sure how to interpret the cups-browsed_log. The "Remote printer overview" section is interesting, particularly where it says things like
cream.local, IP not determined
. The only things logged during the actual print job execution and failure are printer state change notifications that don't seem to be saying anything.I wish I had debug logging enabled from when printing worked fine, so I could see what differs between now and then...
The text was updated successfully, but these errors were encountered: