CUPS 2.3.3op1: Possible delays when starting CUPS, autopkg tests in debian/tests/ not working
Hi,
in the OpenPrinting fork of CUPS we got a contribution from Zdenek
Dohnal switching cups to the systemd service typoe "notify":
----------
commit e96e96b4bd0d4e6f634bbb66b95d6e475501541c
Author: Zdenek Dohnal <zdohnal@redhat.com>
Date: Wed Nov 25 08:12:32 2020 +0100
[Fedora] cups.service.in: Use 'notify' service type and run after
network.target
1) If the service is defined with 'simple' type, the result of
'systemctl' is 0 regardless of actual startup result, because it reports
success/failure of forking process (even before cupsd is started). This
way errors due bad configuration or programming errors are masked during
systemctl invocation.
The 'notify' type depends on executable sending a 'Im running' type
of message to systemd after successful start and systemctl's return code
depends whether this message came or not, which solves the issue.
2) The service needs to be started after all units needed for
network.target are activated. This prevents starting cupsd before we
have ports ready.
Fedora bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1153660 (adding
network.target)
https://bugzilla.redhat.com/show_bug.cgi?id=1088918 (change of the
service type)
----------
This makes systemd waiting for cupsd giving an "I am up and running"
notification on the socket /run/systemd/notify. As cupsd is under
AppArmor control it cannot write to this socket and systemd gets stuck
until reaching a timeout. This timeout leads to a significant delay when
starting cupsd and also to the failure of all autopkg tests.
To fix this I have added
# CUPS is of systemd service type "notify" now, meaning that cupsd
notifies
# systemd when it is up and running, give CUPS access to systemd's
# notification socket
/run/systemd/notify w,
to the AppArmor profile debian/local/apparmor-profile in
cups_2.3.3op1-5ubuntu1.
I recommend to update the Debian package appropriately.
Till
Reply to: