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.
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.