Description of problem: 1) Printing to cups printer available on the network. 2) Printjob is sent and prints 3)the gnome notification printer icon appears 4)clicking on the applet brings up the status window. 5)Printjob physically completes on the remote printer but the status window never updates the printjob as completed and continues to show the status as Sending. 6)selecting the printjob and choosing to cancel document from the edit menu of the status window doesn't clear the printjob. Version-Release number of selected component (if applicable): desktop-printing-0.15-1 Expected results: When the printjob is physically completed the status show change. and I should be able to cancel and clear all printjobs listed in the status window. -jef"by the way, default printer preference works equally well as the native per application printer chooser dialog in everything i test including this little bugaboo"spaleta
5) Can you surf to http://printserver:631/printers and see whether it picked up on the print job status? 6) Yes...it currently doesn't change until it confirms from the remote end it was actually cancelled. In retrospect it would have been nice to say "Cancelling..." but I already promised the nice GNOME i18n guys I wouldn't change any more strings.
Oh, and: > I should be able to cancel and clear all printjobs listed in the > status window. Do you have a particular reason for wanting to clear them? We thought about having print jobs just go away automatically after 3 days or something. My feeling is that most people log in and out often enough that it should clear their print list.
comment #1 5) cant surf to the remote printer server. Should that be a requirement to be able to print to that printer? comment #2 a particular reason? Lets just say there are certain sensitive filenames that i'm not particularly interested in other people might happen to see because its sitting in the status list. Sensitive because it might be sensitive data because i work at a .gov. Or it might be sensitive because the file name is off-color or adult oriented and I dont necessarily want other people to see the name of the file i printed sitting in the list. -jef
5) You need to be able to reach the printer via IPP, which goes over HTTP. Can you do: telnet server 631 ?
If that doesn't work, some tcpdump output would be useful. tcpdump -s 0 -w ~/tcpdump.log 'host myprintserver and port 631'
Re: comment #4 telnet server 631 doesn't connect. attached is the tcpdump.log on http and telnet attempts to 631 I'll repeat all this again when i'm physically at the boxes to make sure it is still printing.
Created attachment 105377 [details] tcpdump on client to printerserver port 631
From the tcpdump output, it looks like you were using Firefox to browse to the port. Can you capture the output of printing something (small :)) and let eggcups appear, and wait a few seconds? Then I should be able to see what IPP requests eggcups is doing. Alternatively, you could: strace -s 200 -p $(pidof eggcups) >/tmp/eggcups.log 2>&1
Re: comment #8 I did a new tcpdump active while i sent a 1 page document to the cups server from gedit. waiting a few seconds after the print job was done for eggcups to update...nothing. Then tried to browse to the 631 port on the cups server and got a forbidden. The print job goes through just fine, but eggcups status isnt updating, still shows "Sending" New attachment in a minute.... -jef
Created attachment 105484 [details] tcpdump on client to printerserver port 631 with a small printjob sent over.
Hmm. Do you have control over the CUPS server? If so can you attach its configuration? It looks to me like eggcups is requesting status about the print job, but isn't getting anything back. Then something (I guess it must be eggcups) tries to request status on /, which is forbidden. I'm not sure why that would happen. How did you set up this printer? Is it picked up automatically via local network CUPS broadcast? Or did you add it with system-config-printers as a local printer? Something else?
"Do you have control over the CUPS server?" Its an fc2 fully updated desktop under my complete control and subject to my every whim. Well at least while my wife isn't actively using it. As far as configurations go, the system hasnt been tweak far from the defaults for an fc2 workstation install. "If so can you attach its configuration?" Which configuration files do you want exactly from the server? I configured the printer via the system-config-printer dialog on the cups server. "Then something (I guess it must be eggcups) tries to request status on /, which is forbidden" That was probably me being stupid and trying to surf via a webbrowser to http://server:631/ again after the print job finished and before i shutdown the tcpdump log. "How did you set up this printer?" system-config-printer on the server, setup as a local parallel port printer. "Is it picked up automatically via local network CUPS broadcast?" yes, on the client machine its being picked up as a Browsed que, when I examine the printer listings in s-c-printer.
I just want the cups.conf. That should list the access control on the server. Have you ever used system-config-printer on your client system? Also, can you run gnome-session-properties and remove eggcups from your session, and then from a terminal, run: eggcups -d --sm-disable 1>/tmp/eggcups.log 2>&1 And just print something, then attach eggcups.log here.
Uhm cups.conf? as in /etc/dbus-1/system.d/cups.conf? i would have thought you would want /etc/cups/cupsd.conf I'll attach both just to save time. along with the eggcups.log -jef
Created attachment 105566 [details] eggcups -d --sm-disable 1>/tmp/eggcups.log 2>&1
Created attachment 105567 [details] /etc/cups/cupsd.conf on cups server
Created attachment 105568 [details] /etc/dbus-1/system.d/cups.conf on cups server
[0x8813dd8] [ec_job_model_job_sent_remote] ec-job-model.c:585 (20:32:24): no job for local 3 remote 27 Now we're getting closer. This means that eggcups couldn't find the job on the remote server. The typical reason for this is a permissions problem, but your remote cupsd.conf looks OK (Although I'm not sure why you have "Deny from All" and "Allow from All" in the config for Canon). One more thing: can you do: strace -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1 and then print something and attach the eggcups.strace here. Hopefully we'll get to the bottom of this :)
Created attachment 105628 [details] strace -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1
Ok, here are the relevant messages: read(19, "l\4\1\0\220\0\0\0r\0\0\0\2\0\0\0\1o\0\0\32\0\0\0/com/redhat/PrinterSpooler\0\2s\0\0\0\31\0\0\0com.redhat.PrinterSpooler\0\3s\17\0\0\0JobQueuedRemote\0\10s\0\0\6\0\0\0ssuuss\0\7s\0\0\0\5\0\0\0:1.93\0\0\0\0\0\0\0s\0\0\0*\0\0\0ipp://karen.localdomain:631/printers/Canon\0s\r\0\0\0successful-ok\0u\0\4\0\0\0u\0\0\0\34\0\0\0s\0\0\0\10\0\0\0jspaleta\0s\0\0\5\0\0\0Canon\0", 2048) = 258 read(19, 0x8f58738, 2048) = -1 EAGAIN (Resource temporarily unavailable) clone(child_stack=0xf68fb4c8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0xf68fbbf8, {entry_number:6, base_addr:0xf68fbbb0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xf68fbbf8) = 27800 From here we can see that we're getting the JobQueuedRemote dbus signal from the cups server, and we create a thread to retrieve the job data from the server. But it doesn't look like the calls from the other thread are in the strace. Could you try rerunning with: strace -fF -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1 The -fF tells strace to follow threads.
Created attachment 105685 [details] strace -fF -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1
I also have the problem of finished print jobs remaining in the "print status" window. Both jobs are shown as "sending". Both have finished printing, one of them 2 days 19 hours ago.
Jef: I am baffled, honestly. I don't understand why a POST to / is happening; it should be to /printers/Canon. I can see from your earlier debug output that the correct printer URI is being retrieved. redhat.uk: can you attach the same debug info that Jef did? Remove eggcups from your session as in comment 13, then get the output of: eggcups -d --sm-disable 1>/tmp/eggcups.debuglog 2>&1 # Do a print job, wait till you see eggcups flash, then Ctrl-C it strace -fF -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1 # Do another print job, wait till you see eggcups flash, then Ctrl-C it
Ok, actually - it looks to me like a POST to / is normal; my mistake. If you guys change your CUPS configuration like so: <Location /> Order Deny,Allow Allow From All </Location> does it work as expected?
I tried comment #24, then ran a service cups restart. Same problem. The Status is still shown as "Sending". I'll follow the request from comment #23.
Created attachment 105828 [details] [user@box ~]$ eggcups -d --sm-disable 1>/tmp/eggcups.debuglog 2>&1
Created attachment 105829 [details] [user@box ~]$ strace -fF -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1
redhat.uk: Did you remove the existing eggcups from your session? The debug log shows you already had one running. Jef: Can you also confirm that allowing POST to / for all clients doesn't help you either?
<Location /> Order Deny,Allow Allow From All </Location> on the server and a cups service restart later.... my eggcups printjob on the client desktop shows status complete a few seconds after the job is actually done. Now...give me my history flush.. or I'll tell slashdot that you allowed this status bug to exist. -jef
Tim - The default CUPS configuration denys POST to /, which prevents eggcups from getting status updates on jobs. Do you know what the security implications of allowing this would be? Would anyone on the network be able to e.g. cancel jobs?
> Did you remove the existing eggcups from your session? Yes. I ran eggcups -d --sm-disable 1>/tmp/eggcups.log 2>&1 I just tried it again. The log says the same.
Concerning 'Location /' permissions: the documentation suggests that this location is for 'get' operations and so shouldn't be too harmful to open up. I don't think it would allow anyone external to cancel jobs. However, I'm not sure that allowing everyone on the network to view your currently printing jobs is entirely desirable either. But I suppose that's what eggcups needs?
Can't eggcups be fixed instead? Rather than letting anyone look at print jobs on my computer? Just asking.
Tim: Yes, eggcups needs to be able to retrieve the job status. What you really want of course is only for users who submitted a job to be able to retrieve its status. The only way I can think of to implement this sanely is Kerberos. Which we don't have yet :/ We should at least relnote this, that the default cups configuration doesn't allow print job monitoring to work. Although - I wonder if it would work if I hacked eggcups to use the printer URI for POST instead of /. Let me try that.
Well, there is a /jobs namespace that cups provides. If I change eggcups to use that, then I get prompted for a password with the office CUPS setup. This may just be a misconfiguration of our office CUPS server though. Tim: Any opinion?
Ok, it is going to be hard to change it to use the printer URI. I'll see if I can do it though.
Ok, I took a stab at this. Can you guys try: Binary: http://people.redhat.com/walters/desktop-printing-0.17-4.i386.rpm Source: http://eople.redhat.com/walters/desktop-printing-0.17-4.src.rpm Be sure to revert your CUPS configuration to the default.
I'm afraid I can't test the rpm right now, python is behaving weirdly. Will test when I can.
Jef - do you think you could try the RPM? It's also in rawhide.
sorry i was a way at a conference for a week. I should be able to test this sometime today while the other machine isn't in use. Just to be clear, you want me to install the desktop-printing package on one of my fc3 or fc2 client computer while talking to a stock cups server running on fc2? -jef
Well your not going to like the results I reverted the fc2 cups server back to the default cupsd.conf restarted the cups service and i installed the desktop-printing-0.17-4.i386.rpm on the fc3 client and then logged into the fc3 desktop sent a printjob via gedit to the remote printer document print status is still stuck at Sending...even though the printjob has completed... no obvious change from the user perspective. I'll do it again and produce an strace to attach. -jef
Created attachment 107157 [details] strace -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1 after desktop-printing-0.17-4 installation
Hm, can you redo that with -fF too?
Created attachment 107268 [details] strace -fF -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1 for desktop-printing-0.17-4
Man, I suck. I added the patch to the package, but forgot to actually apply it. Can you try this? http://people.redhat.com/walters/desktop-printing-0.17-5.i386.rpm
:-> desktop-printing-0.17-5.i386.rpm seems to have worked the gui dialog changed from status printing to status completed. I'll attached the strace log for completeness for you to inspect. -jef"now... back to my real complaint...being able to flush the list of completed printjobs from the dialog"spaleta
Created attachment 107353 [details] strace -fF -s300 eggcups --sm-disable 1>/tmp/eggcups.strace 2>&1 for desktop-printing-0.17-5
Colin, I'm getting ready to move my fc2 machine running the remote cups server over to fc3, unless you need me to do more specifically about this issue. If this isn't resolved to your satifaction I can do more testing against the same fc2 machine to avoid complicating the testing scenario. So just let me know if I need to do anything else. -jef
Ok, let's go ahead and close this bug; please open separate ones about other issues such as cancellation not working (I think you mentioned that).
I just tried desktop-printing-0.17-5.i386.rpm from Rawhide and it did not fix the problem for me. The job completed 10 minutes ago, but is still listed in the printer applet as "Unknown" document (it did have a file name), "?" size, and "Sending" status. The applet flashed briefly when it appeared, but stopped after a second or so (after spooling completed?). The target printer was an HP network printer's IPP interface, not another Linux/CUPS box. FWIW, I like the old apparent behavior where the applet disappeared if there was nothing in the queue. Also, I tend to stay logged in for long periods of time on machines under my physical control. It would be nice not to have to look at this artifact.
I tried printing to an FC2 CUPS system, and I see the correct behavior now. The icon greys out and the submitted job shows with the correct information: filename, printer-queue, size, age, and status (Completed). My remarks in Comment #51 still apply for a non-FC IPP queue. Haven't tried other types of queues yet.
Matthew: can you open a new bug, and attach the strace data like in Comment 20 to it? A new bug would be nice because I think the main issue in this bug has been fixed (eggcups not working with the default CUPS config), and I'd like to track your issue separately.
OK See 142015.
The print jobs also do not clear out of the eggcups notification window for me. After applying the rawhide rpm listed above, the status says "printing", then it changes to unknown. This is also on fedora core 3. I notice in my logs that FC3 is attempting to access the status every few minutes and I see the lines: D [15/Dec/2004:08:43:13 -0600] ReadClient() 30 POST /printers/q626 HTTP/1.1 E [15/Dec/2004:08:43:13 -0600] get_job_attrs: job #15214 doesn't exist! D [15/Dec/2004:08:43:13 -0600] Sending error: client-error-not-found D [15/Dec/2004:08:43:13 -0600] ProcessIPPRequest: 30 status_code=406 In the log.
Ah wait, think I may have solved my own problem. I think this depends on the "Preserve Job History" option being set in the cupsd.conf file. Flipping that on makes the printer grey out after the job has been completed. Okay, now the real kicker is to be able to clear the list so the jobs don't rack up. We at the University of Kansas, Department of Mathematics have confidential government projects being printed and require this feature. Most of our faculty members involved in these projects stay logged in for months at a time. Our userbase is approximately 200 people.
Ok, in desktop-printing-0.18-1, I just added a new menu item "Edit->Clear Completed Documents". This should address the other complaint in this bug about sensitive documents. There is another bug if that you never log out, the list just accumulates; I plan to address that by automatically clearing completed documents after 1 day.