Hello, On Feb 19 18:56 Jean Hendrickx wrote (shortened):
Hi, using SuSE 9.0 and CUPS, we've a Frame Relay printer server with 3 printers, and ... almost everything works fine; but from time to time (almost once a week), one printer (no always the same), gots disabled and /var/log/cups/error_log have:
W [03/Feb/2004:10:53:35 -0400] [Job 875] Remote host did not respond with command status byte after 300 seconds! E [03/Feb/2004:10:53:35 -0400] PID 15078 stopped with status 1!
I.e. you are using the LPD protocol (and therefore the lpd backend). It should work much better when you use the socket backend instead. See the Administration Manual.
I think this can be because a fault (off line) printer or lack on bandwidth ... CUPS didn't see the printer as online and disables it;
Yes.
but how can I tell CUPS to check the printer's status to put it back online every 5 mins or so?
Use a cron job which does /usr/bin/enable for all queues. Background information: It depends on the particular backend whether or not it gives up or does endless retries. If a backend finishes with non-zero exit code then the cupsd disables the queue. This is perfectly o.k. because it is the backend (and only the backend) which must decide whether or not to retry or to tell the cupsd that it had failed. It doesn't make sense when a backend gives up with zero exit code because this indicates that the job was successfully sent to the printer (i.e. the cupsd would remove the job from the spool). It doesn't make sense when the cupsd doesn't disable the queue when a backend results a non-zero exit code because why should it work to start with a new job or the same job again. As far as I know for example neither the parallel nor the socket backend cause such problems. Both backends do endless retries. In particular the lpd backend seems to cause such problems. I think that it may be a nice feature to have additional parameters for all backends regarding timeout and retries. For example something like lpd://server/name?timeout=30+retries=0 to do endless retries. For example it may make sense to be able to specify something like socket://host:port?timeout=60+retries=1440 to disable the queue when there is no connection possible within 24 hours. At the moment the lpd backend has a timeout parameter (see for example http://www.cups.org/sam.html#LPD_OPTIONS) but no parameter regarding the number of retries. In particular for the lpd backend something like lpd://server/name?timeout=86400 may be a solution for this problem (86400 seconds is 24 hours). Kind regards Johannes Meixner -- SUSE LINUX AG, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/