cups-browsed repeatedly deletes/recreates a healthy driverless IPP-Everywhere queue via a self-triggering on_printer_modified() loop

Summary

cups-browsed periodically tears down and recreates an already-working, unchanged implicitclass:// queue for a driverless IPP-Everywhere printer discovered via DNS-SD, roughly every 5-50 minutes with no external trigger (network state is stable, printer is idle and reachable the whole time). Debug logging shows this is caused by on_printer_modified() reacting to its own settings-backup action as if it were a new external modification, creating a self-triggering loop that sometimes cascades into a full delete-and-recreate of the queue. Each cycle fires a CUPS PrinterAdded/PrinterModified D-Bus notification, which downstream desktop components (e.g. GNOME's gsd-print-notifications) surface as a repeated "Printer Added" toast, even though nothing about the printer or network actually changed.

Environment

• OS: Ubuntu 26.04 LTS (Resolute Raccoon)
• Kernel: 7.0.0-27-generic
• cups-browsed: 2.1.1-0ubuntu3
• cups/cups-daemon/cups-client/cups-common: 2.4.16-1ubuntu1.3
• cups-filters: 2.0.1-0ubuntu4.1
• libcups2t64: 2.4.16-1ubuntu1.3
• Printer: HP LaserJet MFP M235sdw, discovered via DNS-SD (_ipps._tcp and _ipp._tcp, host NPIDE7C12.local), driverless/IPP-Everywhere (printer-make-and-model: HP Printer, driverless, 2.1.1)
• Queue backend: implicitclass://HP_LaserJet_MFP_M235sdw_DE7C12/
• Network: single stable WiFi interface throughout (wlp0s20f3), no interface/IP changes during the observed cycles
• /etc/cups/cups-browsed.conf (non-default/active lines only):

  BrowseRemoteProtocols dnssd
  DebugLogging stderr
  

What we ruled out before finding this

• Avahi was scoped to a single real interface (allow-interfaces=wlp0s20f3 in /etc/avahi/avahi-daemon.conf) - no change.
• This machine happened to have two independent cups-browsed instances running in parallel (the apt-packaged cups-browsed.service and a separate one bundled in the OpenPrinting cups snap, cups.cups-browsed), which we confirmed via a live D-Bus capture were both racing to manage the same queue (one's deletion explicitly logged as caused by the other). Disabling the duplicate snap-managed instance reduced noise but did not stop the core loop - it still reproduces with a single cups-browsed instance running cleanly.
• Captured org.freedesktop.Avahi.ServiceBrowser D-Bus traffic for 6+ hours during active reproduction and saw nothing - cups-browsed appears to talk to Avahi via libavahi-client directly rather than over D-Bus, so this isn't an Avahi re-announcement race visible at that layer.

Reproduction (debug log excerpt, DebugLogging stderr via systemd journal)

A tight self-triggering loop, five on_printer_modified() cycles in about 2 seconds with no external event between them:

Jul 09 00:48:19 cups-browsed[1198880]: on_printer_modified() in THREAD 126351861545856
Jul 09 00:48:19 cups-browsed[1198880]: [CUPS Notification] Printer modified: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" modified by "cups-browsed".
Jul 09 00:48:21 cups-browsed[1198880]: Settings of printer HP_LaserJet_MFP_M235sdw_DE7C12 got modified, doing backup.
Jul 09 00:48:21 cups-browsed[1198880]: on_printer_modified() in THREAD 126351861545856
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer modified: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" modified by "cups-browsed".
Jul 09 00:48:21 cups-browsed[1198880]: Settings of printer HP_LaserJet_MFP_M235sdw_DE7C12 got modified, doing backup.
Jul 09 00:48:21 cups-browsed[1198880]: on_printer_modified() in THREAD 126351861545856
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer modified: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" is now available.
Jul 09 00:48:21 cups-browsed[1198880]: Settings of printer HP_LaserJet_MFP_M235sdw_DE7C12 got modified, doing backup.
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer state change on printer HP_LaserJet_MFP_M235sdw_DE7C12: Now accepting jobs.
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer state reasons: paused
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer state change on printer HP_LaserJet_MFP_M235sdw_DE7C12: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" state changed to idle.
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer state reasons: none
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer state change on printer HP_LaserJet_MFP_M235sdw_DE7C12: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" state changed.
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer state reasons: none
Jul 09 00:48:21 cups-browsed[1198880]: on_printer_modified() in THREAD 126351861545856
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer modified: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" modified by "cups-browsed".
Jul 09 00:48:21 cups-browsed[1198880]: Settings of printer HP_LaserJet_MFP_M235sdw_DE7C12 got modified, doing backup.
Jul 09 00:48:21 cups-browsed[1198880]: on_printer_modified() in THREAD 126351861545856
Jul 09 00:48:21 cups-browsed[1198880]: [CUPS Notification] Printer modified: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" modified by "cups-browsed".
Jul 09 00:48:21 cups-browsed[1198880]: Settings of printer HP_LaserJet_MFP_M235sdw_DE7C12 got modified, doing backup.

About 7 minutes later this escalated into a full delete-and-recreate of the (still perfectly healthy) queue, again with no external trigger:

Jul 09 00:55:07 cups-browsed[1198880]: Printer discovered 1 times:
Jul 09 00:55:07 cups-browsed[1198880]: Printer discovered 0 times:
Jul 09 00:55:07 cups-browsed[1198880]: [CUPS Notification] Printer deleted: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" deleted by "cups-browsed".
Jul 09 00:55:13 cups-browsed[1198880]: on_printer_modified() in THREAD 126351861545856
Jul 09 00:55:13 cups-browsed[1198880]: [CUPS Notification] Printer modified: Printer "HP_LaserJet_MFP_M235sdw_DE7C12" is now available.

We also captured the corresponding org.cups.cupsd.Notifier D-Bus signals directly (via dbus-monitor --system "interface='org.cups.cupsd.Notifier'") confirming cupsd really does emit a fresh PrinterAdded for each recreation, which is what desktop notification daemons key off of:

member=PrinterDeleted: "Printer \"HP_LaserJet_MFP_M235sdw_DE7C12\" deleted by \"cups-browsed\"."
member=PrinterStopped: "Printer \"HP_LaserJet_MFP_M235sdw_DE7C12\" state changed to stopped."
member=PrinterAdded:   "Printer \"HP_LaserJet_MFP_M235sdw_DE7C12\" was added."
member=PrinterModified: "Printer \"HP_LaserJet_MFP_M235sdw_DE7C12\" is now available."

Expected behavior

cups-browsed should not treat its own settings-backup side effect as an externally-originated printer modification, and should not repeatedly delete/recreate a queue for a printer whose DNS-SD presence and IPP attributes haven't actually changed.

Impact

Every cycle produces a desktop "Printer Added" notification (observed via GNOME on Wayland, but the underlying mechanism is the CUPS D-Bus notifier, not GNOME-specific), recurring indefinitely at irregular intervals for as long as the printer stays on the network. No print functionality is lost, but the recurring notification is a persistent, unexplained annoyance to end users, and this has previously led to workarounds like disabling cups-browsed or masking avahi-daemon entirely, both of which sacrifice legitimate DNS-SD printer discovery to work around this bug.

Start at the on_printer_modified() entry point and trace the settings-backup action alongside the CUPS notification callbacks. Reproduce with DebugLogging stderr and inspect the systemd journal and CUPS notifier signals. Done means a healthy unchanged DNS-SD queue remains without a self-triggering modification loop or delete/recreate notifications.