Bug 244001
| Summary: | Cups delays printing after next reboot (network printer) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicolò <nicko87> | ||||||
| Component: | cups | Assignee: | Tim Waugh <twaugh> | ||||||
| Status: | CLOSED CANTFIX | QA Contact: | |||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 7 | ||||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-06-29 09:03:09 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 236808 | ||||||||
| Attachments: |
|
||||||||
|
Description
Nicolò
2007-06-13 09:48:16 UTC
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. |