Switch OFF printer 'stop' feature?

Helge Blischke h.blischke at srz.de
Sat Jul 30 07:30:37 PDT 2005


Peets wrote:
> 
> On reflection, the majority (read: +90%) of the problems I have had with CUPS is a fully randomised desire to go into 'stop printer' mode.  There is rhyme nor reason to it, and it's not a feature that will be of great value in SME and end user configurations.  It may be different in Gnome, but in KDE KPrinter will not even provide access to that facility (as it needs root level access), so an end user is stuck as the localhost:631 port needs user authentication to set up before it works, and giving end users access to root level just to fix a recurring printer problem strikes me relatively insane as well - it would be nice if it didn't happen in teh first place.
> 
> Or, put another way, this problem is, in my experience, contributor #1 to users eventually giving up on the Linux desktop.
> 
> I would very seriously welcome a switch that will permanently disable this 'feature' so that those of us who try to get people away from spyware infested environments can actually have confidence we don't lead them into another set of problems.  As a matter of fact, the random stops are not of much help in a production server either..
> 
> Until such time as a switch becomes available, I guess we're stuck with glorious workarounds like hammering the printer into 'enable' mode every five minutes: witness the kind of scripts as below:
> 
> ==============
> #!/bin/sh
> 
> COUNTER=0
> 
> while [ $COUNTER -lt 1 ]; do
> DATE=$(date +%Y-%m-%d-%T)
> PRINTERSTOPPED=$(lpstat -p | grep disabled | awk '{print $2}')
> MESSAGE=$(echo "Printer $PRINTERSTOPPED was stopped! $DATE")
> 
> if [ -n "$PRINTERSTOPPED" ]; then
> lpstat -p | grep disabled | /usr/bin/enable $(awk '{print $2}')
> echo $MESSAGE | mail -s "$MESSAGE" webmaster at example.com
> fi
> 
> sleep 300
> done
> ================
> 
> (source: http://tinyurl.com/88efv - www.mailug.org)
> 
> Rather insane as a solution, but it indicates a kind of desparation.
> 
> *NOT* good.
> 
> = P =

Well, I can't talk about parallel, serial, or USB printers, as all the bunch of printers
at our site are connected via socket 9100 and the appropriate protocol.

But, occasionally, we encounter the "stopped printer syndrome" as well, but as far as we
can tell, it is always due to some misfunction on the printer's side which the CUPS backend
cannot handle without the risk of spool job loss. In the case of the port 9100 printers
(usually HP printers equipped with JetDirect cards), this occurs whenever the printer
decides to close the connection (both the socket backend and the hpnpf backend are designed
to initiate the connection shutdown by the backend). I think you will agree that the backend
has no chance to evaluate the cause of the failure (at least on reasonable cost); it may be
- in our cases - a printer failure as well as some network issue (e.g. the network being
excessively used by some other "partners").

In short, my advice would be to thorougly attach the printer(s) and use only reliable
printers.

For medium to karge scale installations, I could think of equipping CUPS with an
a SNMP interface or similar to integrate it into a centralized management and
supervising environment.

Helge

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de




More information about the cups mailing list