Bug 1897023 - Cups service restart sequence during upgrade incorrect
Summary: Cups service restart sequence during upgrade incorrect
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 33
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-11-12 05:47 UTC by Ryan
Modified: 2020-11-12 13:47 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-11-12 13:47:04 UTC
Type: Bug

Attachments (Terms of Use)

Description Ryan 2020-11-12 05:47:47 UTC
Description of problem:
The cups RPM scriptlet that performs a restart of the cups.socket and cups.service doesn't observe the required order for these units. 

Version-Release number of selected component (if applicable):

and previous versions back to F31

How reproducible:
every upgrade

Steps to Reproduce:
1. Upgrade cups, note error message
2. see journalctl -xe and confirm that the cups.socket unit failed to start because cups.service was still running.

Actual results:
sudo journalctl -xe

cups.socket: Socket service cups.service already active, refusing.
Failed to listen on CUPS Scheduler.

Expected results:
cups.service stopped before cups.socket attempted to start/stop

Additional info:
This can be worked around by manually stopping cups.service and then starting cups.socket

Comment 1 Zdenek Dohnal 2020-11-12 13:47:04 UTC
Hi Ryan,

thank you for reporting the issue!

However, if cups.service is running (either it is enabled and running by itself or activated via cups.path), cups.socket will always return an error and changing the order in RPM scriptlet didn't change anything according my testing.

%systemd_postun_with_restart uses 'systemctl try-restart' with every unit which takes as a parameter. The operation seems to be atomic, so no ordering from unit files is applied. So when it tries to restart cups.socket, it fails if cups.service is already running (regardless the reason).

The solution can be to make cups.socket listen on port 631 instead of /run/cups/cups.sock, but it is rejected by upstream due systemd bug/design https://github.com/apple/cups/issues/4930#issuecomment-264758127 .

Or disable some of those units, but it will affect the functionality - you will need to have cups.service running permanently if you disable .path and .socket.
Or if you disable cups.service, you need to start once cups.service manually (which will create keepalive file for cups.path) and have cups.socket and cups.path running.

Since it is a harmless warning - the cupsd functionality isn't affected, I'll redirect %systemd_postun_with_restart output to /dev/null.

Closing as RAWHIDE.

Note You need to log in before you can comment on or make changes to this bug.