Re: On-demand launching via socket activation
On Wed, 2014-09-10 at 12:55 -0400, Matthias Clasen wrote: I think its a great idea. If you want to propose it, we can discuss it in the next WG meeting (I sadly saw this too late for the one that just ended...). OK. I've filed this: https://fedorahosted.org/workstation/ticket/8 Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On-demand launching via socket activation
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.
*/
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On-demand launching via socket activation
On Wed, Sep 10, 2014 at 1:53 PM, Tim Waugh twa...@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On-demand launching via socket activation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/2014 07:53 AM, Tim Waugh 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?
It's also worth noting that FESCo granted the WGs the rights to make
decisions like this, so I'd recommend asking the Workstation WG for
permission to add this to their systemd preset file. I suspect it will
be granted.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlQQUqAACgkQeiVVYja6o6PH+QCfaeqpTW4OTbrwB6VleTfKaMxg
qn8AnRARXgxUgD6UcA+bNGPGyYMv0Udr
=TkEz
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On-demand launching via socket activation
On Wed, 2014-09-10 at 14:10 +0200, drago01 wrote: As written today you should ask for an exception ... but I agree that the policy needs to be revised. A good start to revising it is here: https://fedorahosted.org/fpc/ticket/208 e.g. == If a service is enabled by default after installation and has both a socket activated and a non-socket activated unit file set, then it SHOULD enable the socket activated version and leave the non-socket activated unit file off. (But the packager might choose not to do this if he has good reasons for it.) == But that ticket hasn't been touched since it was filed in 2012. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On-demand launching via socket activation
On Wed, 2014-09-10 at 09:31 -0400, Stephen Gallagher wrote: Should I apply for an exception of some sort, or does the socket activation policy need revisiting? It's also worth noting that FESCo granted the WGs the rights to make decisions like this, so I'd recommend asking the Workstation WG for permission to add this to their systemd preset file. I suspect it will be granted. I think its a great idea. If you want to propose it, we can discuss it in the next WG meeting (I sadly saw this too late for the one that just ended...). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
