On-demand launching via socket activation

[drago01]

On Wed, Sep 10, 2014 at 1:53 PM, Tim Waugh <twaugh at redhat.com> wrote:
> 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?

As written today you should ask for an exception ... but I agree that
the policy needs to be revised.