On Sun, 25 Jun 2023 at 19:26, Ansgar <ans...@43-1.org> wrote: > > Hi, > > On Sun, 2023-06-25 at 18:51 +0100, Luca Boccassi wrote: > > Patch attached and pushed to > > https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=hea > > I support this as using the compat layer with systemd-sysv-generator > has some limitations that confuse users (e.g., behavior of "start" as > the unit stays running due to RemainAfterExit=yes set). We should > really aim at providing native systemd units. > > There is one part I think should not be changed: we currently don't > require integration with service management at all. That should > probably not be changed. So please consider reverting > > +--- > | Packages that include system services must include ``systemd`` service > +--- > > to the original > > +--- > | Packages that include system services should include ``systemd`` service > +---
How about: -Packages that include system services should include ``systemd`` service -units to start or stop those services. +Packages shipping system services should integrate with service management. +If they choose to do so, they must include ``systemd`` service units to start +or stop those services. Kind regards, Luca Boccassi
From 73ff234d23464acdcc08c78312c267d51749c64e Mon Sep 17 00:00:00 2001 From: Luca Boccassi <bl...@debian.org> Date: Sun, 25 Jun 2023 18:42:29 +0100 Subject: [PATCH] system services: make systemd units mandatory systemd upstream will drop support for the transitional sysv generator in the near future. The transition is long finished, and it's time for the tail of packages still shipping only init scripts but not units to be updated. --- policy/ch-opersys.rst | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 207b3c0..af4b159 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -328,15 +328,12 @@ Starting system services Introduction ~~~~~~~~~~~~ -Packages that include system services should include ``systemd`` service -units to start or stop those services. See :manpage:`systemd.service(5)` -for details on the syntax of a service unit file. In the common case that -a package includes a single system service, the service unit should have -the same name as the package plus the ``.service`` extension. - -If the package does not include a service unit (if, for example, no one -has yet written one), including an init script, as described below, to -start the service is encouraged. +Packages shipping system services should integrate with service management. +If they choose to do so, they must include ``systemd`` service units to start +or stop those services. See :manpage:`systemd.service(5)` for details on the +syntax of a service unit file. In the common case that a package includes a +single system service, the service unit should have the same name as the +package plus the ``.service`` extension. Packages including a service unit may optionally include an init script to support other init systems. In this case, the init script should have the @@ -345,13 +342,13 @@ it and use the service unit instead. Packages may also support other init systems by including configuration in the native format of those init systems. -If a service unit is not present, ``systemd`` uses dependency information -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide -which scripts to run and in which order. The ``sysv-rc`` runlevel system -for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which -scripts to run and in which order at boot time and when the init state (or -"runlevel") is changed. See the ``README.runlevels`` file shipped with -``sysv-rc`` for implementation details. Other alternatives might exist. +``systemd`` uses dependency and ordering information contained within the +enabled unit files to decide which services to run and in which order. +The ``sysv-rc`` runlevel system for ``sysvinit`` uses symlinks in +``/etc/rcn.d`` to decide which scripts to run and in which order at boot +time and when the init state (or "runlevel") is changed. See the +``README.runlevels`` file shipped with ``sysv-rc`` for implementation details. +Other alternatives might exist. The sections below describe how to write those scripts and configure those symlinks. -- 2.39.2
