<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 25, 2009, at 8:47 AM, Paul Landers wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000">...</font></div></blockquote><blockquote type="cite"><div>The PostScript job again fails, and the printer data light flashes until powered OFF.<br>Here is the bad part:<br>CUPS reports the job(s) completed.<br>On the Linux CUPS server, the 'top' command shows an orphaned PID named "socket" that is consuming 100% of CPU until it is killed.<br>If the user sends multiple copies of the same problematic job, then multiple orphaned PIDs are present, dividing the 100% CPU among themselves until all are killed.<br></div></blockquote><div><br></div>What version of CUPS are you using?</div><div><br></div><div>What Linux distribution?</div><div><br></div><div>Is you queue really pointed at socket or a wrapper backend like beh or Tea4CUPS?</div><div><br></div><div><blockquote type="cite"><div>My point in this posting is that:<br><br>1. CUPS reports the job 'complete' when it never actually printed.<br></div></blockquote><div><br></div>Most of the backends have no way to verify that a job has been printed.</div><div><br></div><div>For socket, there is a "standard" where you close your side of the socket when you are done sending data and the printer closes its side of the socket when it is done printing. Not all printers support this, but most do.</div><div><br></div><div><blockquote type="cite"><div>2. Any unrelated jobs that were sent behind the problematic job are also reported as complete, but were in fact lost too and never printed.<br></div></blockquote><div><br></div>Again, if the printer is accepting connections and data then we have no way to know there is a problem. Particularly with socket, there is no higher-level protocol to report the current printer or job status.</div><div><br><blockquote type="cite"><div>3. There is no CUPS GUI method for average users to recover from the problem (i.e. kill the orphaned PIDs).<br></div></blockquote><div><br></div>Unless you have a bad wrapper backend, CUPS never reports a job as completed until all of the filters and the backend have exited, so users can cancel a job to terminate them. Orphan PIDs should never happen unless cupsd crashes, which is thankfully a rare occurrence.</div><div><br></div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>________________________________________</div><div>Michael R Sweet, Senior Printing System Engineer</div></div></div></span></span>
</div>
<br></body></html>