Help: CUPS print queue is disabling

[jjscott]

I am running CentOS 5.4 with CUPS v1.3.7 and have a Brother printer (MFC-5895CW) that connects wirelessly to a SonicWall device. The SonicWall is hardwired to my PC. I have found that periodically, the printer queue will become disabled and the only way to re-enable it is to issue a cupsenable command.

I believe that queue only gets disabled if the wireless connection drops in the middle of a print job. I've tried dropping the wireless connection and then bringing it back up when no print jobs are active or pending and the queue is fine for the next print job that is sent when the connection is up.

I did a little research and found that my version of CUPS contains support for an ErrorPolicy setting in the printer.conf file that may prevent the print queue from being disabled. I'm hoping that if I change the default value from "stop-printer" to "retry-job" that this will prevent CUPS from disabling the print queue and requirring a cupsenable command to re-enable the queue.

I don't want to play around with scheduling cron jobs to enable the queue. I want a seamless solution.

I can't test until Monday since the system in question is at work.

Can anyone confirm that this will do the trick?

Thanks!

[Rubberman]

Well, that is certainly worth trying. I might look into that myself, since my print queues experience a similar condition when I have my Android phone plugged into the usb port (my printer is a USB device) as well. Anyway, let us know if that helps resolve the problem.

[jjscott]

Thanks. I'll let you know if it works.

Does anybody else know if this will work or have any suggestions?

[jjscott]

After setting the ErrorPolicy to Retry-Job, it fixed the issue...kind of. The print queue was not disabled if the wireless connection was dropped during a print job. However, we did notice some scenarios where the print queue is left in a unusable state that a cupsenable or service cups restart will not restore it to normal functionality. We basically had to reboot the PC to get it to recover.

The Abort-Job setting did work for us. When the wireless connection is dropped mid-print job, only that job is lost. Pending jobs in the queue are maintained and begin printing once the connection is re-established.

Still not sure why the default setting for the ErrorPolicy is set to disable the queue.

Thanks