Bug 512442

Summary:	Printers widget think printing is still occurring even though it has completed
Product:	[Plasma] plasmashell	Reporter:	John Veness <john.kde>
Component:	Printers widget	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	martin.schnitkemper, noeerover
Priority:	NOR
Version First Reported In:	6.5.2
Target Milestone:	1.0
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description John Veness 2025-11-21 16:13:52 UTC

SUMMARY
After a print job has finished, the Printers widget still thinks that printing is happening.

STEPS TO REPRODUCE
1. Make sure that Printers widget is set to "Shown when relevant"
2. Print something
3. Note the Printers widget appears
4. Wait for the printing to finish

OBSERVED RESULT
The Printers widget is still present. Hovering over it shows "Printing (job name) with (queue name)". Clicking on the widget, the printer shows "Idle" underneath the name. Clicking on the printer, underneath Configure Printer and View Print Queue, it shows the job name with a Cancel button alongside.

EXPECTED RESULT
The Printers widget to disappear into the overflow area. Hovering over it in the overflow area to show "Print queue is empty". Expanding the printer in the widget to not show any jobs underneath Configure Printer and View Print Queue.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20251119
KDE Plasma Version: 6.5.2
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.0
Kernel Version: 6.17.8-1-default (64-bit)
Graphics Platform: X11

ADDITIONAL INFORMATION
Note that if I view the full print queue, no print jobs are showing, so the problem seems to be just a display issue in the widget.

This used to behave as in the EXPECTED RESULT section. I don't print very often so I can't be certain when the problem first started, but it was quite recently, so maybe with 6.5.

Comment 1 Martin Schnitkemper 2025-12-10 12:04:32 UTC

I can confirm this behavior. After printing, the icon remains in the system tray. When you open it, the printer is shown as "idling," and the print queue displays it as "completed." However, the last job is still displayed with the "Cancel" button, even though it's already finished. The "Cancel" button doesn't do anything because there's nothing to cancel. Only after logging out and back in to the desktop does the icon disappear.

Operating System: Arch Linux 
KDE Plasma Version: 6.5.3
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1
Kernel Version: 6.17.9-arch1-1 (64-bit)
Graphics Platform: X11

Comment 2 Mike 2025-12-10 12:44:07 UTC

It appears we're not getting notification that the job queue is cleared, but I can't reproduce this in 6.5 or master.

Any chance you could try this out with Plasma 6.6?

Comment 3 Mike 2025-12-10 13:03:21 UTC

Also, what version of CUPS are you running?

Comment 4 John Veness 2025-12-10 16:05:52 UTC

I can't test Plasma 6.6 right now, but I am running CUPS 2.4.14.

Comment 5 Mike 2025-12-10 17:20:07 UTC

Alright, I have found a scenario this can happen and it appears to be related to a CUPS dbus-notifier lock that is not released or is "stuck".  Plasma version doesn't matter, but if for some reason, a dbus-notifier get stuck (hangs), we stop getting notified of CUPS events, like for example, a print job finishing.  Even restarting the plasma shell has no effect.  Short of a complete logout, the following seems to put CUPS back into a working state:

Logout of plasma
Switch to a TTY
login
systemctl stop cups
rm /etc/cups/subscriptions.*
rm -rf /var/cache/cups
systemctl restart cups
logout
Switch back to SDDM, start the plasma session

As to why this happens, I'm not really sure.  It's possible a crashing process that holds a notification subscription would prevent a clean "unlock" of the notifier, but I see no evidence that is happening.

Plasma will generally have two processes running that "listen" for CUPS events, one is the marker level checker (kded process) and the other is the plasmoid, (plasmashell process).   Both seem to operate normally and react properly to signals that are received and they log no errors or warnings in this scenario.

Comment 6 Mike 2025-12-10 17:24:39 UTC

I should follow that up with this:  If you see plasmashell crash or a kded crash, then that could possibly cause this behavior because both will attempt to restart and continue on.