cups-browsed high-cpu usage

[Raffaele Rialdi]

The cups-browsed service always use a very high amount of CPU (200%).
This happens on multiple Virtual Machine hosted by Ubuntu on KVM.
I could reproduce the issue on both Intel and AMD x64 cpu architecture.

The VMs had Ubuntu 23.10 and now are on Ubuntu 24 fully updated, but the issue continues.

Initially the cups-browsed was running as a snap service, then I disabled it because of the CPU issue.
After that, Ubuntu automatically enabled the service as `systemctl` which I cannot disable anymore (if I do, it gets re-enabled).
The network is a small office with some printers connected, therefore it is definitely possible there are network announcements for printers being turned on or off, but it's too hard to understand if those events are related to the moment where the service loop into the high CPU usage.

Please other fix the issue or provide a reliable way to shut this service down definitely.

This report was generated by: `ubuntu-bug cups-browsed`

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: cups-browsed 2.0.0-0ubuntu10
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Jun 3 16:34:35 2024
InstallationDate: Installed on 2024-02-16 (108 days ago)
InstallationMedia: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1)
Lpstat:
 device for CANONC700: ///dev/null
 device for Lexmark_CS417dn: implicitclass://Lexmark_CS417dn/
 device for Lexmark_CX410de: implicitclass://Lexmark_CX410de/
 device for Lexmark_MS810: implicitclass://Lexmark_MS810/
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
 Bus 001 Device 003: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Lsusb-t:
 /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M
     |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 480M
     |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 480M
 /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 5000M
MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
Papersize: a4
PpdFiles:
 Error: command ['fgrep', '-H', '*NickName', '/etc/cups/ppd/Lexmark_CS417dn.ppd', '/etc/cups/ppd/Lexmark_MS810.ppd', '/etc/cups/ppd/Lexmark_CX410de.ppd'] failed with exit code 2: grep: /etc/cups/ppd/Lexmark_CS417dn.ppd: Permission denied
 grep: /etc/cups/ppd/Lexmark_MS810.ppd: Permission denied
 grep: /etc/cups/ppd/Lexmark_CX410de.ppd: Permission denied
ProcEnviron:
 LANG=en_US.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-31-generic root=UUID=3bb2f1ef-40f7-4a13-b608-ffbc1c1e873d ro quiet splash vt.handoff=7
SourcePackage: cups-browsed
UpgradeStatus: Upgraded to noble on 2024-05-30 (4 days ago)
dmi.bios.date: 04/01/2014
dmi.bios.release: 0.0
dmi.bios.vendor: SeaBIOS
dmi.bios.version: 1.16.3-debian-1.16.3-2
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-q35-8.0
dmi.modalias: dmi:bvnSeaBIOS:bvr1.16.3-debian-1.16.3-2:bd04/01/2014:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-8.0:cvnQEMU:ct1:cvrpc-q35-8.0:sku:
dmi.product.name: Standard PC (Q35 + ICH9, 2009)
dmi.product.version: pc-q35-8.0
dmi.sys.vendor: QEMU

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Joseph Garvin (k04jg02)]

This just happened to me on a laptop running Ubuntu 24 directly, not under a VM, including the specific symptom of 200% CPU usage. My laptop has 4 cores / 8 threads so it's not just something consuming all cores, seems like a bug that very specifically causes two threads inside cups-browsed to start spinning. `kill $PID` did not work, I had to use `kill -9`. Possible context: I had since last cold boot printed a document, then today I suspended by closing the lid, went to a cafe and worked, suspended again, plugged laptop in when I got home, then noticed the CPU usage sometime later. So it's possible you need to have started a print job and gone through a suspend cycle to trigger this, but it's only happened once so far so I can't confirm. I did work for a couple hours without noticing it though so I don't think it happens immediately on resume (it's easy to notice because all the fans start going).

[3vi1 (launchpad-net-eternaldusk)]

This randomly happens on my 24.10 (devel repos) desktop. I don't have to have even printed anything.

[Mirek Varecha (altean)]

Unfortunately same situation. I killed cups-browsed in System monitor and started it again using 'sudo systemctl start cups-browsed'

[Lama Zeug (lama500)]

100 % usage of one CPU by cups-browsed in 24.04.

Stopping it helps after more than a minute (service cups-browsed stop).

Feels the same as the bug in older OS versions:
https://bugs.launchpad.net/ubuntu/+source/cups-browsed/+bug/2018504
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/2017907

Is there a simple procedure to produce logs or other information that can help repairing this?

[DavidKoot (davidkoot)]

Start seeing this, twice on two different laptops with Ubuntu 24.04. These laptops have never been used for printing anything. They had no other applications running, except nautilus maybe, one was even with the cover closed. In both cases the laptop was lying without being used for some hours. When I picked it up, fan was spinning at max speed, computer almost too hot to touch, and 'cups-browsed' running at 200% cpu at the one and 300% cpu at the other. Even though I'm a long time Ubuntu user, I never noticed this process before this weekend. Makes me think that some update this week makes this process go into a frenzy.

[Raffaele Rialdi (raffaeler)]

From what I understand the trigger of the bug is not a printing action, but UPnP (Universal Plug and Play) that printers usually do to advertise their presence and services over the network.

Whatever the trigger is, the code that goes in an infinite recursion should be cut with a counter/timeout so that it is impossible to happen again.