Hi,
I'd like to have the default cups presets be:
enable cups.socket
enable cups.path
disable cups.service
In other words, I'd like cupsd to start when accessed locally
via /var/run/cups/cups.socket, and when there are unprocessed files in
the spool directory, but not otherwise.
It looks like the packaging policy prevents that though. I'm trying to
track down the rationale behind this part of the packaging policy:
==>
1.3.2 Socket activation
Socket activation occurs when a service allows systemd to listen for
connections to a specific socket and, when systemd receives a connection
on that socket, it starts the service. To do this, the upstream source
needs to have some minor coding work to let systemd listen for
connections on the socket and there needs to be a .socket file in
%{_lib}/systemd/system/ that tells systemd to listen to that socket and
what to start when a connection is received. This is similar in function
to inetd and some, but not all, services coded to work with inetd will
work with socket activation. ***Simila to inetd, using socket activation
for on-demand loading will impose a startup time penalty so we currently
do not use this feature in Fedora.***
<== (my emphasis)
It looks like this "Socket Activation" section was added on March 9th
2011. The only FPC meeting prior to that mentioning socket activation
was on January 19th 2011:
[...]
17:10:58 <abadger1999> All services (started by systemd, xinet.d, bus
activated, etc) should not be turned on by the package unless they are
granted an exception. The exceptions are listed on this page along with
reasons that the exception was granted which may lead to more general
rules in the future:
[...]
The cups.socket unit passes the listening socket to cupsd, and only
starts one instance of cupsd, so I don't think the "start-up time
penalty" reason applies to it.
Should I apply for an exception of some sort, or does the socket
activation policy need revisiting?
Tim.
*/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
