Thank you very much for the patch.
I have applied it now to he upstream code of cups-filters (BZR rev. 7672).
Note that the error message
"Unable to create/modify CUPS queue (Success)!"
is actually caused by another bug which I had already fixed earlier. The
queue has actually been created but CUPS has returned a non-zero value.
In the beginning I assumed all non-zero values as errors, but CUPS has
some non-zero values which are not errors. In cups-filters 1.13.4 I have
fixed this and since then successfully created CUPS queue do not get
On 08/09/2017 01:00 PM, Cédric Dufour - Idiap Research Institute wrote:
On 09/08/17 10:02, Cédric Dufour - Idiap Research Institute wrote:
I confirm this issue is still present is current Debian Stable/Stretch and
renders CUPS unusable in network printing environments.
I could backport the packages from testing or experimental, but then I would
miss the updates from the Debian Security team (and looking at the updates
history of CUPS filters/browsed in Debian OldStable/Jessie, it is not something
I'm looking forwards to)
I tracked down the issue to a timeout when 'cups-browsed' interacts with the local 'cups'
server ("cupsDoFileRequest" call).
The 'cups-browsed' hard-coded timeout for such operations is 3 seconds.
This timeout is the cause of the witnessed "Unable to create/modify CUPS queue
(Success)!" error messages (and 'cups-browsed' looping infinitely in attempts to add
the failing printers/queues)
For large (fancy ?) PPDs, the local 'cups' server can take up to 8 (!) seconds
to process the addition of a remote printer queue based on the PPD retrieved
from the (BrowsePoll-ed) server (as witnessed on a 3.4GHz Intel I7-2600K test
host, during wich one CPU core is stuck at 100%).
The attached patch file - for cups-filters 1.11.6 (Debian/Stretch) - allows one to configure the
timeouts of both local and remote 'cups-browsed' HTTP connections, thanks to the new
"HttpLocalTimeout" and "HttpRemoteTimeout" configuration settings. Setting the
former to 10 seconds fixed the issue with my troublesome PPDs/printers (INEO+ copiers).
Please note that this issue will still be present in 'cups-browsed' 1.16.0
along 'cups' 2.2.4, as backported from Testing and *verified* on Stretch.
(it should not be difficult to forward-port the attached patch, however)
I hope this patch can meet your approval for its addition in Debian patches
series and considered even for current Stable release (knowing that enterprise
environments with big printing beasts will be bound to stumble on the same
And do you have a privileged contact to propose this patch be included upstream