Do print jobs in CUPS rely on printer UUID or ID, and what happens if they change after pod restart using cups-browsed with PVC?

[paulboby1]

Do print jobs in CUPS rely on printer UUID or ID, and what happens if they change after pod restart using cups-browsed with PVC?

We are running a CUPS setup inside Kubernetes using cups-browsed for printer discovery and auto-configuration. Our setup uses Persistent Volume Claims (PVCs) to retain the following data across pod restarts:

/etc/cups/printers.conf

/var/spool/cups

We observed that when the client pod is deleted and recreated:

The printer ID or UUID changes (as seen in the printers.conf file).

The previously queued print jobs (which were in the var/spool/cups directory) do not resume printing or get reassigned to the new printer instance, even though the printer name appears the same.

1. Do print jobs in CUPS get associated internally with the printer's UUID or ID instead of just the printer name?

2. If yes, does changing the printer UUID or ID (which can happen via cups-browsed on pod recreation) break the link between existing print jobs and their destination printer?

3. How can we ensure print jobs persist correctly and continue printing after pod restarts when using cups-browsed for discovery?

4. Is there a way to force cups-browsed to maintain the same UUID/ID or preserve mapping to resume jobs reliably?

Any insights on how to handle this in a Kubernetes environment with cups-browsed and persistent storage would be appreciated.

[michaelrsweet]

1. Do print jobs in CUPS get associated internally with the printer's UUID or ID instead of just the printer name?

Not on the server, no. However, on the client side having a network printer disappear and then reappear with a new UUID will cause problems.

cups-browsed adds a layer of complexity and will happily delete local queues (and any local jobs) as soon as the remote queues go away...

2. If yes, does changing the printer UUID or ID (which can happen via cups-browsed on pod recreation) break the link between existing print jobs and their destination printer?

See above.

3. How can we ensure print jobs persist correctly and continue printing after pod restarts when using cups-browsed for discovery?

You may not be able to using cups-browsed.

4. Is there a way to force cups-browsed to maintain the same UUID/ID or preserve mapping to resume jobs reliably?

That would be a question for the cups-browsed project...