Hi,
I can confirm this on Debian 13 (cups 2.4.10-3+deb13u2, cups-browsed
1.28.17-6+deb13u1) on two clients printing to a shared queue on a
Debian 13 CUPS server. With DebugLogging enabled, I can see how the
queue ends up unmanaged:
1. A job prints successfully but remains in the local queue
("job-printing"). The server's access_log shows the client sending
Cancel-Job 35 seconds after Send-Document, which the server rejects
because the job is already completed:
23:33:34 "POST /printers/..." Send-Document successful-ok
23:34:09 "POST /printers/..." Cancel-Job client-error-not-possible
Client error_log: "[Job 2] Unable to cancel print job."
I don't know why the client cancels the job.
2. When cups-browsed is stopped (restart or shutdown) while that job is
still listed, it keeps the queue instead of removing it:
Queue has still jobs or CUPS error!
Disabled printer 'O_Brother_Where_Art_Thou_lalaserver'
3. The remaining queue has no "cups-browsed" option in printers.conf
(only "DeviceURI implicitclass://..."). After the next start,
cups-browsed no longer treats it as its own:
Found CUPS queue/class: O_Brother_Where_Art_Thou on host lalaserver.local.
Queue name O_Brother_Where_Art_Thou_lalaserver already taken.
From then on every job fails with "No destination host name supplied
by cups-browsed ..." until the queue is deleted manually.
Step 3 is what upstream commit 57d9351 addresses (implicitclass:// queues
are always treated as cups-browsed-controlled), so a backport to trixie
should prevent the permanent breakage.
Workaround in use here: cups-browsed masked, printing via CUPS' own
driverless DNS-SD destinations. That works reliably.
Thanks!
