Bug 475913
| Summary: | large file sent to cups disappears without a trace | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Kamens <h1k6zn2m> | ||||
| Component: | cups | Assignee: | Tim Waugh <twaugh> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 11 | CC: | twaugh | ||||
| 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: | 2009-07-29 02:21:07 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: | 446451 | ||||||
| Attachments: |
|
||||||
This seems to be the trouble: E [10/Dec/2008:21:23:51 -0500] [Job 16046] No files, canceling job! Looking at the cupsdReadClient lines, is the file actually transferred to the server? You could set "PreserveJobFiles Yes" in /etc/cups/cupsd.conf in order to keep all of the job files in /var/spool/cups; that might give us clues. The "No files, canceling job" message is clearly mistaken. I just set PreserveJobFiles to yes and then printed the big job from picasa again, and again it disappeared into the ether. When I look at /var/spool/cups with "ls -l --si", here's what i see at the end: -rw-r----- 1 root lp 168M 2008-12-10 17:28 d16032-001 -rw-r----- 1 root lp 168M 2008-12-10 17:41 d16033-001 -rw-r----- 1 root lp 168M 2008-12-10 17:50 d16034-001 -rw-r----- 1 root lp 168M 2008-12-10 18:02 d16035-001 -rw-r----- 1 root lp 168M 2008-12-10 18:17 d16036-001 -rw-r----- 1 root lp 67M 2008-12-10 18:20 d16037-001 -rw-r----- 1 root lp 101M 2008-12-10 18:33 d16042-001 -rw-r----- 1 root lp 101M 2008-12-10 18:57 d16043-001 -rw-r----- 1 root lp 168M 2008-12-10 21:24 d16046-001 -rw-r----- 1 root lp 242M 2008-12-11 22:59 d16054-001 The last file is the one I just printed. So yes, it is getting sent to cups. And like I said, if I disable the color2 printer before printing, and then enable afterwards, it prints fine (I didn't do that in this case, so it didn't print). Interesting: When I open the print status applet and tell it to view completed jobs, it says that the job I just tried to print was "Aborted". When right-click on it and select "Reprint", it works. I guess this probably still happens in 1.4b2..? Still seeing this with cups-1.4-0.b2.2.fc11.i386. This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Are you still seeing this with the current version, cups-1.4-0.rc1.10.fc11? If so I'm hoping that the error_log might have more useful information in this time. I can no longer reproduce this issue. |
Created attachment 326579 [details] cupsd error_log file with debug2 enabled, with noise stripped out With current packages from rawhide including cups-1.4-0.b1.4.fc11.i386... I have a raw printer called "raw" set up to print to port 9100 on a remote printer. I multiple printers with "real" drivers set up, all of whom feed into the raw printer queue over ipp (to serialize jobs to the actual printer). One of the printers that feeds into the raw printer, "color2", is configured with the HP Color LaserJet 5550 Foomatic/hpijs driver. When I print a 100MB PostScript file to color2 from the Linux version of picasa, it disappears into the ether -- Picasa thinks it printed, the CUPS logs don't show any errors, and yet it never prints. If I disable the color2 printer with cupsdisable before printing from picasa, and then reenable it afterwards with cupsenable, the file *does* print, i.e., it goes from the color2 queue into the raw queue and from there to the actual printer. I enabled debug2 logging when the problem manifests. Attached is the result, with all of the cupsdDoSelect and cupsdReadClient lines removed to make the log file a reasonable size. I can't figure out from this log file what's going wrong.