(Note conflict between manual configuration and hardware enablement.) |
(Mostly complete) |
||
| Line 1: | Line 1: | ||
== | == What is a Service? == | ||
For the purposes of this document, a "service" is defined as one or more of: | For the purposes of this document, a "service" is defined as one or more of: | ||
* A daemon or process started using a [http://www.freedesktop.org/software/systemd/man/systemd.service.html systemd service unit]. | * A daemon or process started using a [http://www.freedesktop.org/software/systemd/man/systemd.service.html systemd service unit]. | ||
| Line 9: | Line 7: | ||
Note that this includes processes which are not persistent. If something started by a systemd service unit runs for a short period of time and then exits, it is still a service. An example would be <code>iptables</code>. | Note that this includes processes which are not persistent. If something started by a systemd service unit runs for a short period of time and then exits, it is still a service. An example would be <code>iptables</code>. | ||
== Enabling Services by Default == | |||
Only services that meet all criteria below are permitted (but not required) to be enabled by default on package installation. | |||
=== Must not alter other services=== | === Must not alter other services=== | ||
| Line 14: | Line 15: | ||
=== Must not require manual configuration to function === | === Must not require manual configuration to function === | ||
The service must not require configuration before it starts properly. If the end-user/administrator must make some specific configuration change before the service is able to start without error | The service must not require configuration before it starts properly. If the end-user/administrator must make some specific configuration change before the service is able to start without error then it MUST NOT be enabled by default. | ||
XXX | XXX Note that this allows services to start by default as long as they simply exit without error until they have been configured. I can't decide if this is a good thing, but to do otherwise could conflict with hardware support services below. | ||
=== Must not listen for outside connections === | === Must not listen for outside connections === | ||
| Line 26: | Line 27: | ||
Some hardware requires some additional service to be started in order to be useful. This may come in the form of a non-persistent setup process or in the form of a continuously-running service. If the service can be hardware activated to only start when the relevant hardware is present and do nothing when not present, and otherwise it meets the above requirements, then it SHOULD be enabled by default upon package installation. | Some hardware requires some additional service to be started in order to be useful. This may come in the form of a non-persistent setup process or in the form of a continuously-running service. If the service can be hardware activated to only start when the relevant hardware is present and do nothing when not present, and otherwise it meets the above requirements, then it SHOULD be enabled by default upon package installation. | ||
If the service cannot be hardware activated, but it is possible to configure it such that it | If the service cannot be hardware activated, but it is possible to configure it such that it will exit without error and without marking the service as "failed" according to systemd, then it SHOULD be enabled by default upon package installation. This clean exit may be accomplished through [https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionArchitecture=| systemd conditionals], by having the service (or a wrapper script) perform hardware detection and exit without indicating an error, or via other similar means. | ||
If there is value in the service optionally failing in some instances (for example, when hardware which is expected to be present is removed or stops functioning) then this behavior MAY be made available using one or more of the following methods: | |||
* An opt-in mechanism involving a userspace tool with proper documentation. | |||
* The saving of state in permanent storage (an appropriate location in /var) to aid in detecting the failure. | |||
== Approved Exceptions == | == Approved Exceptions == | ||
Revision as of 23:09, 18 July 2018
What is a Service?
For the purposes of this document, a "service" is defined as one or more of:
- A daemon or process started using a systemd service unit.
- A daemon or process that is invoked by socket activation, either by using a systemd socket unit, D-BUS activation or similar behavior.
- A daemon or process that is invoked by hardware activation (i.e. started via a udev rule).
- A systemd timer unit that runs periodically.
Note that this includes processes which are not persistent. If something started by a systemd service unit runs for a short period of time and then exits, it is still a service. An example would be iptables.
Enabling Services by Default
Only services that meet all criteria below are permitted (but not required) to be enabled by default on package installation.
Must not alter other services
Installation of the package providing the unit auto-started by this preset may not change the behavior of any other service running (or potentially running) on the system.
Must not require manual configuration to function
The service must not require configuration before it starts properly. If the end-user/administrator must make some specific configuration change before the service is able to start without error then it MUST NOT be enabled by default.
XXX Note that this allows services to start by default as long as they simply exit without error until they have been configured. I can't decide if this is a good thing, but to do otherwise could conflict with hardware support services below.
Must not listen for outside connections
The service must not listen on a network socket for connections originating on a separate physical or virtual machine.
D-BUS services and hardware-activated services generally meet this requirement.
Hardware Support Services
Some hardware requires some additional service to be started in order to be useful. This may come in the form of a non-persistent setup process or in the form of a continuously-running service. If the service can be hardware activated to only start when the relevant hardware is present and do nothing when not present, and otherwise it meets the above requirements, then it SHOULD be enabled by default upon package installation.
If the service cannot be hardware activated, but it is possible to configure it such that it will exit without error and without marking the service as "failed" according to systemd, then it SHOULD be enabled by default upon package installation. This clean exit may be accomplished through systemd conditionals, by having the service (or a wrapper script) perform hardware detection and exit without indicating an error, or via other similar means.
If there is value in the service optionally failing in some instances (for example, when hardware which is expected to be present is removed or stops functioning) then this behavior MAY be made available using one or more of the following methods:
- An opt-in mechanism involving a userspace tool with proper documentation.
- The saving of state in permanent storage (an appropriate location in /var) to aid in detecting the failure.
Approved Exceptions
Some services which are permitted to be enabled by default as specific exceptions. Services that should be enabled by default throughout all of Fedora must be approved by FESCo. Services that should be enabled or disabled by default only on one or more of the Fedora Editions must be approved by those Editions' Working Groups.
Example:
- FESCo approves openssh-server to run by default on Fedora in general.
- Workstation WG approves openssh-server to be disabled by default on the Workstation Edition.