How to preserve printer UUID/ID across restarts in cups-browsed to avoid job loss in Kubernetes with PVC

[paulboby1]

We are running a CUPS setup inside Kubernetes, where printers are dynamically discovered using cups-browsed and we persist important CUPS directories across pod restarts using PVCs (/etc/cups/printers.conf and /var/spool/cups).

Our issue arises when the client pod is deleted and recreated:

The printer UUID/ID changes in printers.conf, even though the printer name remains the same.

The print jobs retained in /var/spool/cups no longer get processed because they are no longer linked to the new printer instance.

This leads to jobs stuck in the spool with “[“No suitable Destination Host found by cups-browsed]” issues or silent failures.

From the CUPS maintainer's response, we understand that:

OpenPrinting/cups#1245

Print jobs on the client side can be affected by changes in printer UUID/ID.

cups-browsed can delete and recreate queues, which in turn breaks job associations.

Is there a recommended way in cups-browsed to persist or reuse the same printer UUID or ID across restarts in Kubernetes?
Alternatively, is there a way to avoid deleting/replacing queues if the discovered printer matches a previously seen printer (e.g., by hostname/IP/DeviceURI), so that queued jobs remain valid?

Our goal is to ensure that jobs in the spool directory can continue printing after a pod restart, especially in high-availability or clustered environments.

[zdohnal]

Hi,

KeepGeneratedQueuesOnShutdown Yes in /etc/cups/cups-browsed.conf might do the trick for you.

Zdenek

[paulboby1]

Hi,

KeepGeneratedQueuesOnShutdown Yes in /etc/cups/cups-browsed.conf might do the trick for you.

Zdenek

Hi its by default Yes right. Also I have done that still after deletion of pod new queue is generated with different uuid and id

[zdohnal]

Aha - I thought you wanted the queues to survive cups-browsed shutdown, not the complete deletion of the container.

Do you feed the pod with printers.conf which was populated by cups on cups-browsed requests? IIRC if cups-browsed recognized the local queue is handled by cups-browsed, it should not be regenerated. The other thing might be if BrowsePoll does not see the queues on destination, thus the cups-browsed controlled queues get removed...

[paulboby1]

Aha - I thought you wanted the queues to survive cups-browsed shutdown, not the complete deletion of the container.

Do you feed the pod with printers.conf which was populated by cups on cups-browsed requests? IIRC if cups-browsed recognized the local queue is handled by cups-browsed, it should not be regenerated. The other thing might be if BrowsePoll does not see the queues on destination, thus the cups-browsed controlled queues get removed...

this is my cups-browsed configuration

BrowseRemoteProtocols CUPS
#BrowseFilter NOT host local
BrowsePoll cups-server-0.cups-service.print.svc.cluster.local:631
BrowsePoll cups-server-1.cups-service.print.svc.cluster.local:631
#BrowsePoll cups-server-2.cups-service.print.svc.cluster.local:631
DomainSocket /var/run/cups/cups.sock
AllowResharingRemoteCUPSPrinters No
NewBrowsePollQueuesShared Yes
OnlyUnsupportedByCUPS No
LocalQueueNamingRemoteCUPS RemoteName
AutoClustering Yes
LoadBalancing QueueOnServers
DNSSDBasedDeviceURIs Yes
CreateIPPPrinterQueues No
CreateRemoteCUPSPrinterQueues Yes
CreateRemoteRawPrinterQueues No
IPBasedDeviceURIs No
CacheDir /var/cache/cups
LogDir /var/log/cups
DebugLogging file stderr
BrowseInterval 30
BrowseTimeout 120
KeepGeneratedQueuesOnShutdown Yes
https://docs.google.com/document/d/1zWwo8j1DVGM6_8YV5X6Y78d45jWUzr5PO90JuXfYmQw/edit?usp=sharing

This is my printers.conf present in one of my cups-client
root@cups-client-0:/etc/cups# cat printers.conf
# Printer configuration file for CUPS v2.4.11
# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
NextPrinterId 18

PrinterId 17
UUID urn:uuid:a1ab678e-05b7-3c05-5a6b-d035dd373e91
Info printer1
MakeModel Cluster printer1, driverless, 2.1.1
DeviceURI implicitclass://printer1/
State Idle
StateTime 1746464798
ConfigTime 1746464798
Type 4231246
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job
Option cups-browsed true
Option print-color-mode monochrome

root@cups-client-0:/etc/cups#

[paulboby1]

Aha - I thought you wanted the queues to survive cups-browsed shutdown, not the complete deletion of the container.

Do you feed the pod with printers.conf which was populated by cups on cups-browsed requests? IIRC if cups-browsed recognized the local queue is handled by cups-browsed, it should not be regenerated. The other thing might be if BrowsePoll does not see the queues on destination, thus the cups-browsed controlled queues get removed...

This is my Architecture.

I am having two layers: cups and cups-browsed. In cups layer, we will be having 2 pods running cups-service.
We have manually added same printer (having same name) on both of pods in the cups-layer.

In the cups-browsed layer, we will be having pods running with cups and cups-browsed services. Cups-browsed pods will be polling the printers that are present in the pods of cups-layer. Cluster will be formed pointing to the pods present in the cups-layer.

Print jobs are sent to this cups-browsed layer. While executing print jobs, we have deleted (simulating pod eviction/kill) the cups-browsed pod.

On the recreated pod, pre-existing jobs will be in the processing state with an error "No host destination provided by cups , is cups browsed running?"; while if we sent jobs to the other queue, it will print. To start printing properly on the recreated pod, we need cancel all the jobs in the processing state for that queue. If we send the jobs to the other queue, it will print.