Linux Bazzite: Printer only prints after a restart

Quote from Micha

My PC runs Linux Bazzite. Since one of the latest updates, my printer only prints after I restart the PC. I suspect problems with CUPS, but I’m not really sure. Do you have any idea?

That actually sounds more like a stuck service than a printer that has been permanently configured incorrectly. The fact that printing works again after a restart is an important clue: The printer configuration itself is probably intact, but one of the involved processes either does not restart properly after the update or later loses its connection to the printer.

Under Bazzite, which is based on Fedora, CUPS itself is usually not the only component responsible. Depending on the printer, network discovery via Avahi, a USB-IPP service, or a vendor-specific driver may also be involved. You can think of it as a small supply chain: CUPS accepts the job, a filter processes it, and another service finds or reaches the printer. If one link gets stuck after an update, a complete restart helps—but a more targeted approach would be to restart precisely that link.

The most important first test: When the printer stops printing again, first restart only CUPS without restarting the PC: sudo systemctl restart cups

Then send another print job. If that helps, the cause is very likely CUPS or its current runtime environment. It is also worth checking its status: systemctl status cups --no-pager

If restarting CUPS alone is not enough, check whether the printer is connected over the network. With Wi-Fi and LAN printers, Avahi is often relevant because it discovers printers on the local network via mDNS. As a test: sudo systemctl restart avahi-daemon

With a modern printer connected via USB, ipp-usb may also be involved. This service makes many current USB printers available as network printers on the local computer. In that case, restart it with: sudo systemctl restart ipp-usb

For quick troubleshooting, you can restart these three services one after another when the problem occurs:

• sudo systemctl restart cups
• sudo systemctl restart avahi-daemon
• sudo systemctl restart ipp-usb – only useful for USB printers; if the service does not exist, that is harmless.

You can then use lpstat -t to check how CUPS sees the printer. Messages such as “unable to connect,” “paused,” “filter failed,” or a job that remains queued indefinitely are particularly informative.

The CUPS logs usually provide the clearest indication. Immediately after a failed print attempt, you can run: journalctl -u cups -b --no-pager -n 100. For a USB printer, also run: journalctl -u ipp-usb -b --no-pager -n 100. For network printers, journalctl -u avahi-daemon -b --no-pager -n 100 can also be helpful.

A common special case after updates: The printer was set up with an old vendor-specific driver, while Fedora or Bazzite was updated to a newer CUPS, Python, or filter stack. If your printer is configured as “HP,” “Brother,” “Epson,” or something similar with a proprietary driver, testing a driverless setup would be worthwhile. Modern printers often work more reliably via IPP Everywhere or AirPrint. In the printer management interface, this often appears as “driverless” or “IPP Everywhere.”

For a network printer, I would also check whether it is receiving a changing IP address. After a router restart or a longer standby period, CUPS may still be pointing to an old address. A DHCP reservation in the router or a fixed printer IP often eliminates these problems permanently.

If print jobs remain stuck in the queue, you can remove them after restarting the service and send them again. Use lpstat -o to view queued jobs; cancel -a cancels all jobs. This is sometimes necessary because a job that has already failed is not automatically resumed cleanly.

In practice, I would proceed in this order: First restart CUPS, then—depending on the connection type—restart Avahi or ipp-usb, and afterward review the output of lpstat -t and the CUPS journal messages. If you tell me whether the printer is connected via USB, Wi-Fi, or LAN, what model it is, and what lpstat -t outputs when the problem occurs, the cause can usually be narrowed down quite precisely.