Currently, we don't have any explicit packaging policy regarding socket activated services, but I think we should. A couple of packages could benefit from this, but are currently reluctant to add these given that there's no policy for them yet.

In general I believe socket activation should be supported across the board when possible. Especially in a containerized world socket activation is useful in order to provide a large number services with very little resources. (Think: enabling sshd in 1000 containers would traditionally start 1000 sshd listener processes even though it is seldom used. With socket activation the same would be almost free.) It also adds robustness and uniformity to things, and makes the boot-up much faster. (There are also certain drawbacks however, such as possibly slower connection times on the first and possibly later connections, hence we should in many cases support both a socket activated and a non-socket activated mode).

Here's a bit of brainstorming what I'd like to see in the policy:

1. If socket activation is supported in a service, the package MUST provide socket activation unit files (i.e. a pair of .service and .socket) for it (but not necessarily enable them by default). This includes all services that support inetd-compatible socket activation.

2. If a service supports inetd-compatible activation and previously included an xinetd config snippet for it, it MUST remove this and replace it by a pair of native systemd socket unit and service unit. (i.e. the policy of removing SysV scripts should find its counterpart here in that xinetd snippets need to be removed, too).

3. If a service supports both a socket activated mode and a traditional non-socket activated mode, then it MAY also include unit files for the traditional non-socket activated mode.

4. If the service listens on IP and supports both IPv4 and IPv6 the socket unit MUST be configured to listen on both IPv4 and IPv6.

5. If a service supports both an Accept=yes and Accept=no mode for sockets it is generally recommended to use Accept=no, for performance reasons. (Explanation: some services can be started either in a mode where a single instances handles all connections and takes over the listening socket on activatioon [Accept=no], or in a mode where one instance is spawned for each incoming connection and just takes over the connection socket [Accept=yes]. The former usually yields better performance and should hence be recommended.)

6. If a service supports exit-on-idle it is recommended to make use of this by default, so that the service only runs when actually used.

7. 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.)

The idea here is basically that packages such as sshd and dovecot would ship socket activation units by default and use them by default, but administrators can still switch over to the non-socket activated version, if the start-up latency is an issue for them. Note that MacOS has been using an exclusively socket activated sshd since years, and we should provide a similar default.