Description of problem: Printing a document have no effect immediately, but printed document is somehow saved and printed just after the next reboot Version-Release number of selected component (if applicable): libgnomecups-0.2.2-8 cups-libs-1.2.10-10.fc7 hal-cups-utils-0.6.9-1.fc7 cups-1.2.10-10.fc7 How reproducible: Always Steps to Reproduce: 1. configure network printer (Hp deskjet 845c) attached to USRobotics router 2. print something, nothing happens 3. reboot, document is printed Actual results: Printing delayed until next boot Expected results: Printing should happen within reasonable time, without having to reboot Additional info: I am sure this is not caused by the router or the printer, because the other pc connected to it (Windows XP) prints just after some seconds Also: "/etc/init.d/cups restart" is not enough, it needs to reboot. Sorry I have not tried with direct USB connection of the printer, but can do if required
I'd like some additional information in order to track down the problem. 1. What does 'lpstat -t' say? 2. What does 'lpstat -o' say?
lpstat -t scheduler is running system default destination: Hp device for Hp: http://192.168.1.1:1631/printers/Hpdeskjet845c Hp accepting requests since Wed 13 Jun 2007 11:41:34 AM CEST printer Hp now printing Hp-10. enabled since Wed 13 Jun 2007 11:41:34 AM CEST Connected to 192.168.1.1... Hp-5 fabrizio 55296 Tue 12 Jun 2007 07:00:06 PM CEST Hp-6 fabrizio 55296 Tue 12 Jun 2007 07:03:23 PM CEST Hp-7 fabrizio 55296 Tue 12 Jun 2007 07:26:00 PM CEST Hp-8 fabrizio 55296 Tue 12 Jun 2007 08:30:27 PM CEST Hp-9 fabrizio 55296 Tue 12 Jun 2007 08:30:32 PM CEST Hp-10 nicko 6144 Wed 13 Jun 2007 11:40:38 AM CEST lpstat -o Hp-5 fabrizio 55296 Tue 12 Jun 2007 07:00:06 PM CEST Hp-6 fabrizio 55296 Tue 12 Jun 2007 07:03:23 PM CEST Hp-7 fabrizio 55296 Tue 12 Jun 2007 07:26:00 PM CEST Hp-8 fabrizio 55296 Tue 12 Jun 2007 08:30:27 PM CEST Hp-9 fabrizio 55296 Tue 12 Jun 2007 08:30:32 PM CEST Hp-10 nicko 6144 Wed 13 Jun 2007 11:40:38 AM CEST Please note that document of user nicko (me) still has to be printed If you need something else, just let me know
Don't know if this is useful, but I have found out that reboot is not required: Hybernation is enough
I'd like to try a test print with some debugging on if that's okay. First I'd like to you start with no jobs in the queue. Then, as root: 1. Edit /etc/cups/cupsd.conf so that the 'LogLevel' line reads: LogLevel debug2 2. Stop CUPS: /sbin/service cups stop 3. Clear out the error_log file: >/var/log/cups/error_log 4. Now start CUPS: /sbin/service cups start 5. Submit a print job and give it some time to try printing it. When you have done that, if the job has failed to print please attach the /var/log/cups/error_log file to this bug report as an attachment. Thanks.
Created attachment 157121 [details] CUPS error log Here it is, please let me know if you are also interested in the same log after next boot (when it will print, I'm quite sure about that... )
I have noticed that the file has continued to grow in the past minutes, but it just keeps repeating that cups will delay its job for 11 seconds (d [15/Jun/2007:17:34:03 +0200] select_timeout: 11 seconds to process active jobs d [15/Jun/2007:17:34:14 +0200] cupsdCheckJobs: 1 active jobs, sleeping=0, reload=0 d [15/Jun/2007:17:34:14 +0200] cupsdCheckJobs: Job 12: state_value=5, loaded=yes d [15/Jun/2007:17:34:14 +0200] select_timeout: 9 seconds to send browse update) every 11 seconds, and it is not likely to stop very soon...
Yes, that's expected -- this is with debug logging enabled. You can turn it back off now: 1. edit /etc/cups/cupsd.conf and change the 'LogLevel' line to read: LogLevel info 2. Tell CUPS to reload its configuration: /sbin/service cups reload ~~~ So the ipp backend is getting stuck soon after it connects. I'd like to try another test, this time to see what happens on the TCP connection. 1. Start with no jobs in the queue, as before. 2. In a terminal window, as root, please run this command to capture the TCP traffic: tcpdump -w printer.pcap -U -s 0 port 1631 3. Submit a print job and wait about five minutes, enough to give it time to try to print it. If the job prints successful, try another -- I need to see the log from a *failed* job. 4. Press Control-C to stop tcpdump. 5. Attach the printer.pcap file as an attachment to this bug report. Thanks.
Created attachment 157136 [details] tcpdump How did you know I had to try twice? This is the first time it prints immediately... However, this is the log for the failed one
You didn't tell me if you needed something else...
We send an IPP-Print-Job request to the US Robotics ADSL 4-Port Router device, with 'Content-Length: 17631', however after sending exactly that many bytes there is no response. The problem lies with the US Robotics device.