on Sat, May 15, 2004 at 04:33:24AM -0400, richard lyons (richard@the-place.net) wrote:
> There must be a better way!
>
> Further to recent threads on problem of stopping bad printout:
>
> problem: printer prints many pages of postscript code.
That sounds like a header initialization problem. The sort of thing
which might have been common ten years ago but really *should* be fixed.
Somewhere on the Web is a string of PCL you need to prepend to your
print jobs which says "this is a postscript job, damnit, treat it like
one". Possibly in your CUPS prefilter. But I know nothing about that.
> Job won't stop
...how are you attempting to stop them?
I've found large-caliber, soft-nose bullets generally do the trick,
though a shotgun can work if you don't have time to mess with aim.
> - gives an error something about permission-client. Same problem can
> occur when, for example, printing a 22-page fax and running out of
> toner in the middle, printed job on a different printer to save
> waiting for new (expensive!) toner catridge: once cartridge is
> replaced, if job is already spooled to the host with the printer, it
> cannot be stopped from the source host.
Is it spooled *on* the printer or on the printer-controller's queue?
Latter assumes you centralize administration through a single system.
> solution so far: power down printer, delete printer from cups,
> reinstall and power up printer. This gets rid of the "unstoppable"
> job.
That sounds to me as if CUPS is holding on the the job in _its_ queue.
Most printers _won't_ stop printing a job even if powered down --
they've got local storage for jobs, disk or other HW, and will resume on
power-up.
> remaining problem: Often, the new printer will not run. Error says
> printer port lp0 is blocked (or something similar). Now it is
> necessary to reboot the host as well.
Hrm.
Have you gone through the CUPS and Samba docs _thoroughly_?
I say this with the completely whacked sleep schedule of someone who was
literally up past dawn Saturday after staying at work "for a couple of
hours" to get the printing thing ironed out.
Turns out my issue _was_ sort of addressed and acknowledged in the docs,
but only in a way that was clear in hindsight. Much inference of logs
was required, as the problem wasn't directly stated in any of 'em.
> So, I have two questions:
> 1/ surely there is a way to delete the spool file directly -- it
> must be somewhere. I am not talking about the /var/spool/cups/d*
> file - deleting that does not stop a job from printing
> necessarily. The data evidently go somewhere else after that.
If you're printing *via* Samba *to* CUPS, you've also got your Samba
queue to worry about. /var/spool/samba/ or wherever you've defined it
it.
See Chapter 19 of the Samba HOWTO collection:
http://localhost/doc/samba-doc/htmldocs/CUPS-printing.html
It's good stuff. Denser than lead, but good.
> 2/ surely there is some way to unblock the lp0 port without rebooting the
> whole system. This isn't windoze.
# fuser -vm /dev/lp0
# lsof
...would be my starting points. Kill the attached process.
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Burn all gifs! Use PNG and tell Unisys to go to hell:
http://burnallgifs.org/
Attachment:
signature.asc
Description: Digital signature