Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Sean Whitton]

Hello,

On Sun 07 Apr 2024 at 08:54am +02, Paul Gevers wrote:

> Hi,
>
> On Sat, 09 Sep 2023 18:51:52 -0700 Russ Allbery  wrote:
>
> """
> +``systemd`` uses dependency and ordering information contained within the
> ++enabled unit files to decide which services to run and in which order.
> """
>  ^ is that "+" before "enabled" really intended? It looks weird to me.

Fixed in git, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Paul Gevers]

Hi,

On Sat, 09 Sep 2023 18:51:52 -0700 Russ Allbery  wrote:

"""
+``systemd`` uses dependency and ordering information contained within the
++enabled unit files to decide which services to run and in which order.
"""
 ^ is that "+" before "enabled" really intended? It looks weird to me.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Tue, 12 Sep 2023, 06:13 Russ Allbery,  wrote:

> Sam Hartman  writes:
> >> "Luca" == Luca Boccassi  writes:
>
> > Luca> Thank you, looks good to me, seconded.
>
> > LGTM too, seconded.
>
> Thanks!  This has now been merged for the next Policy release.
>

That's great, thank you!

>

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Sam Hartman  writes:
>> "Luca" == Luca Boccassi  writes:

> Luca> Thank you, looks good to me, seconded.

> LGTM too, seconded.

Thanks!  This has now been merged for the next Policy release.

-- 
Russ Allbery (r...@debian.org)  

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 10:15 PM Russ Allbery  wrote:

> Luca Boccassi  writes:
>
> > systemd upstream will drop support for the transitional sysv generator
> > in the near future. The transition is long finished, it's been at least
> > a decade, and it's time for the tail of packages still shipping only
> > init scripts but not units to be updated.
>
> > Tentatively this should happen within Trixie's development cycle. Of
> > course it's free software and generators are not that difficult to
> > maintain, so if someone wanted to lift the sysv generator out of the
> > systemd repository and adapt it to be a standalone binary there's
> > nothing stopping them. But I wouldn't want the systemd package to depend
> > on such a backward compat tool, so packages needing this hyptothetical
> > package should depend explicitly on it. This is just mentioned for
> > completeness, it's been at least a decade and writing a unit file is
> > beyond trivial so there shouldn't be any issue adding the few remaining
> > ones.
>
> The mass bug filing happened, and although there were some objections on
> debian-devel, I don't think any of them were blocking.  Specifically, I
> did not see anyone present a concrete plan for how to keep the systemd
> unit generator or some equivalent alive, and given that systemd upstream
> is dropping support for this feature, I believe that's the only way for
> this change to not be effective mandatory.
>
> Therefore, I think the time is ripe to proceed with this Policy change.
>
> I took a detailed look at this part of Policy today, and the whole system
> service section needs serious work.  I believe the instructions it
> currently provides for constructing package maintainer scripts won't
> actually work with a current Debian system, and most Debian packages are
> technically violating the current Policy because it hasn't been updated
> for how systemd units work today.  I started on overhauling that section,
> but it became clear that this is going to be a larger project with some
> potentially controversial decisions, so I'm going to open a new bug about
> that so that we don't block this change on that work.
>
> I made the following changes to your last diff:
>
> * Move the "should" about integrating with service management to the
>   parent section.
>
> * Explicitly say that systemd is the default init system and service
>   manager (it feels like we should say this somewhere, and I don't think
>   we already do).
>
> * Add an explicit exception for packages intended only to support
>   alternate init systems.  (As an obvious example, sysvinit isn't going to
>   ship a systemd unit, nor should it.)
>
> * Delete the paragraph suggesting that packages without systemd units
>   should write an init script, since this will no longer accomplish the
>   goal of getting that system service to work with systemd and therefore
>   no longer seems to serve a purpose.
>
> Here is what I came up with.  I think it is ready for seconds or
> objections.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Sun, 10 Sept 2023 at 03:19, Russ Allbery  wrote:
>> 
>> Russ Allbery  writes:
>> 
>> > -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 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.
>> 
>> And of course I have to post the diff to see the bugs.  The part
>> that says "uses the same symlinks" should now say "uses
>> symlinks".

Luca> Thank you, looks good to me, seconded.

LGTM too, seconded.



signature.asc
Description: PGP signature

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 10 Sept 2023 at 03:19, Russ Allbery  wrote:
>
> Russ Allbery  writes:
>
> > -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 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.
>
> And of course I have to post the diff to see the bugs.  The part that says
> "uses the same symlinks" should now say "uses symlinks".

Thank you, looks good to me, seconded.

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Russ Allbery  writes:

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

And of course I have to post the diff to see the bugs.  The part that says
"uses the same symlinks" should now say "uses symlinks".

-- 
Russ Allbery (r...@debian.org)  

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Luca Boccassi  writes:

> systemd upstream will drop support for the transitional sysv generator
> in the near future. The transition is long finished, it's been at least
> a decade, and it's time for the tail of packages still shipping only
> init scripts but not units to be updated.

> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to depend
> on such a backward compat tool, so packages needing this hyptothetical
> package should depend explicitly on it. This is just mentioned for
> completeness, it's been at least a decade and writing a unit file is
> beyond trivial so there shouldn't be any issue adding the few remaining
> ones.

The mass bug filing happened, and although there were some objections on
debian-devel, I don't think any of them were blocking.  Specifically, I
did not see anyone present a concrete plan for how to keep the systemd
unit generator or some equivalent alive, and given that systemd upstream
is dropping support for this feature, I believe that's the only way for
this change to not be effective mandatory.

Therefore, I think the time is ripe to proceed with this Policy change.

I took a detailed look at this part of Policy today, and the whole system
service section needs serious work.  I believe the instructions it
currently provides for constructing package maintainer scripts won't
actually work with a current Debian system, and most Debian packages are
technically violating the current Policy because it hasn't been updated
for how systemd units work today.  I started on overhauling that section,
but it became clear that this is going to be a larger project with some
potentially controversial decisions, so I'm going to open a new bug about
that so that we don't block this change on that work.

I made the following changes to your last diff:

* Move the "should" about integrating with service management to the
  parent section.

* Explicitly say that systemd is the default init system and service
  manager (it feels like we should say this somewhere, and I don't think
  we already do).

* Add an explicit exception for packages intended only to support
  alternate init systems.  (As an obvious example, sysvinit isn't going to
  ship a systemd unit, nor should it.)

* Delete the paragraph suggesting that packages without systemd units
  should write an init script, since this will no longer accomplish the
  goal of getting that system service to work with systemd and therefore
  no longer seems to serve a purpose.

Here is what I came up with.  I think it is ready for seconds or
objections.

-- 
Russ Allbery (r...@debian.org)  

>From 474a9f4c74bc2c3a1d162de33e377a3585e641af Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Sat, 9 Sep 2023 18:39:16 -0700
Subject: [PATCH] systemd unit files are now a must

systemd is dropping support for the generator that allows it to
automatically create units for init scripts. As a result, all
packages that want to integrate with systemd service management
must start shipping systemd units.

State that arranging for services to be automatically started or
stopped is a should, but if the package wishes to do that, a
systemd service unit is a must unless the package is only intended
for use with alternate init systems. Avoid saying that systemd uses
/etc/rcn.d links to determine service ordering.
---
 policy/ch-opersys.rst | 35 ---
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 207b3c0..bee16f2 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -323,20 +323,25 @@ which try to write to a home directory will fail to build.
 Starting system services
 
 
+Debian packages that provide system services should arrange for those
+services to be automatically started and stopped by the init system or
+service manager.  This section describes how that is done.
+
 .. _s-services-intro:
 
 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.
+The default init system and service manager in Debian is ``systemd``.
+Packages that wish to automatically start and stop system services must
+include ``systemd`` service units to do so, unless the service is only
+intended for use on systems running alternate init systems.  See
+:manpage:`systemd.service(5)` for 

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

>> I consider this proposal to be premature. Policy should document
Luca> current
>> practice, and I do not think this proposal does that.

For what it's worth, I agree with Luca that we are ready for a change to
document that service units need to be included now, and I do not think
a change in this area is premature.
I have not (and probably will not get around to) reviewing the specific
text, but I do think it's time for this change now.

(Some of Simon's comments about the security implications of not being
able to depend on systemd for dbus service activation but instead still
needing to support dbus-daemon launching things itself make me think we
should consider even more sweeping changes soon.)

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 30 Jul 2023 23:12:21 +0200 Bill Allombert 
wrote:
> On Sun, Jul 30, 2023 at 08:22:54PM +0100, Luca Boccassi wrote:
> > On Fri, 30 Jun 2023 00:04:29 +0100 Luca Boccassi 
> > wrote:
> > > This happened a few days ago and nobody complained (if we ignore
> > > grumblings because of the fact that I used lintian.debian.org
queries
> > > which are hopelessly and silently out of date, sigh), and bugs
are
> > > filed, there have been a couple of uploads too already.
> > > 
> > > Can we go ahead, or do you want to wait a specified amount of
time?
> > > If
> > > so, how long (just so that I know when to come back)?
> > 
> > Hi, monthly ping. Anything I can do to move this forward?
> 
> I consider this proposal to be premature. Policy should document
current
> practice, and I do not think this proposal does that.

Not really - apart from the fact that it's been 10 years or so, and if
after a decade something can still be 'premature' then we'll all be
long dead before anything becomes 'mature'. More importantly, the clock
is ticking, and anything not shipping a unit file but still expecting
to work will break in the near future. So the policy change right now
would be correct - current practice is to ship at least a unit file for
anything shipping a service, and not doing that is a bug, of which the
severity is going to increase shortly, as the affected package will
stop working in the default scenario.

> It would it more useful to help maintainers adapt their script to
conform
> to this first, and change policy later.

The help already arrived - bugs have been filed notifying of the
required changes. If anybody has the time and interests in doing
anything more than that, that's great, the bug list is linked earlier
in the thread.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Bill Allombert]

On Sun, Jul 30, 2023 at 08:22:54PM +0100, Luca Boccassi wrote:
> On Fri, 30 Jun 2023 00:04:29 +0100 Luca Boccassi 
> wrote:
> > This happened a few days ago and nobody complained (if we ignore
> > grumblings because of the fact that I used lintian.debian.org queries
> > which are hopelessly and silently out of date, sigh), and bugs are
> > filed, there have been a couple of uploads too already.
> > 
> > Can we go ahead, or do you want to wait a specified amount of time?
> > If
> > so, how long (just so that I know when to come back)?
> 
> Hi, monthly ping. Anything I can do to move this forward?

I consider this proposal to be premature. Policy should document current
practice, and I do not think this proposal does that.
It would it more useful to help maintainers adapt their script to conform
to this first, and change policy later.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Fri, 30 Jun 2023 00:04:29 +0100 Luca Boccassi 
wrote:
> This happened a few days ago and nobody complained (if we ignore
> grumblings because of the fact that I used lintian.debian.org queries
> which are hopelessly and silently out of date, sigh), and bugs are
> filed, there have been a couple of uploads too already.
> 
> Can we go ahead, or do you want to wait a specified amount of time?
> If
> so, how long (just so that I know when to come back)?

Hi, monthly ping. Anything I can do to move this forward?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 25 Jun 2023 11:21:53 -0700 Russ Allbery  wrote:
> Luca Boccassi  writes:
> 
> > systemd upstream will drop support for the transitional sysv
generator
> > in the near future. The transition is long finished, it's been at
least
> > a decade, and it's time for the tail of packages still shipping
only
> > init scripts but not units to be updated.
> 
> Has there already been a mass bug filing for packages that ship init
> scripts but not systemd unit files?
> 
> > Tentatively this should happen within Trixie's development cycle.
Of
> > course it's free software and generators are not that difficult to
> > maintain, so if someone wanted to lift the sysv generator out of
the
> > systemd repository and adapt it to be a standalone binary there's
> > nothing stopping them. But I wouldn't want the systemd package to
> > depend on such a backward compat tool, so packages needing this
> > hyptothetical package should depend explicitly on it. This is just
> > mentioned for completeness, it's been at least a decade and writing
a
> > unit file is beyond trivial so there shouldn't be any issue adding
the
> > few remaining ones.
> 
> > Once the policy is updated I plan to ask Lintian to bump the
severity
> > of the existing check:
> 
> > https://salsa.debian.org/lintian/lintian/-/merge_requests/407
> 
> Assuming the mass bug filing hasn't already happened and I missed it,
I
> think this is the wrong order.  This sort of large-scale breaking
change
> should always start with a mass bug filing against all affected
packages.
> I think the right process is:
> 
> * Raise this in debian-devel and propose a mass bug filing requiring
all
>   packages to add systemd unit files if they currently only have init
>   scripts.  This gives people the opportunity to object or take over
>   maintenance of the unit file generator and document how to depend
on it
>   if they wish to do that instead.  (I don't think that's a good
idea, but
>   we should let the discussion happen.)
> 
> * Unless something surprising happens in that discussion, do a mass
bug
>   filing for this transition and bump the Lintian severity at the
same
>   time.
> 
> * Once that has consensus and is underway, *then* change Policy to
reflect
>   this project decision.
> 
> If the mass bug filing already happened and I just didn't notice, my
> apologies.

This happened a few days ago and nobody complained (if we ignore
grumblings because of the fact that I used lintian.debian.org queries
which are hopelessly and silently out of date, sigh), and bugs are
filed, there have been a couple of uploads too already.

Can we go ahead, or do you want to wait a specified amount of time? If
so, how long (just so that I know when to come back)?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Benda Xu]

Luca Boccassi  writes:

>> I take care of packages that do not meet the proposed policy. And I
>> don't have a systemd test environment.  I am curious what is the
>> recommended way to go forward.
>>
>> - upload a generator-converted .service without any test;
>> - set low-NMU to encourage interested party to upload a .service;
>> - leave the lack-of-systemd-service bug open until some one submit a
>>   patch or a merge request;
>> - you name it.
>
> Have you already tried booting a test environment in a container
> (lxc/nspawn/podman/docker) or in a VM?

Thanks, Luca.  That's doable.

The problem is that I am now too overloaded and therefore less motivated
to maintain a test environment that I don't use myself.

Russ Allbery  writes:

> systemd unit files for "typical" daemons are very simple to write (simpler
> than an init script in a lot of cases) and generally don't change much.  I
> would, if I were you, be tempted to just write an obvious and simple unit
> file and upload it and let people report bugs if it breaks.  This isn't
> ideal, but at least for simple daemons the risk is probably relatively
> low?  Maybe I'm too cavalier, though.
>
> I suspect there are also a fair number of people who would be happy to
> help write systemd unit files for packages, since (at least in my opinion)
> it's kind of fun.  This isn't the right place to coordinate that, but
> there must be some good spot in Debian.  debian-mentors, maybe?

Thanks Russ!  Your comments alleviated my hesitations to go for option
1.  Then hopefully everyone would be happy :)

Yours,
Benda

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Benda Xu  writes:

> I take care of packages that does not meet the proposed policy. And I
> don't have a systemd test environment.  I am curious what is the
> recommended way to go forward.

> - upload a generator-converted .service without any test;
> - set low-NMU to encourage interested party to upload a .service;
> - leave the lack-of-systemd-service bug open until some one submit a
>   patch or a merge request;
> - you name it.

systemd unit files for "typical" daemons are very simple to write (simpler
than an init script in a lot of cases) and generally don't change much.  I
would, if I were you, be tempted to just write an obvious and simple unit
file and upload it and let people report bugs if it breaks.  This isn't
ideal, but at least for simple daemons the risk is probably relatively
low?  Maybe I'm too cavalier, though.

I suspect there are also a fair number of people who would be happy to
help write systemd unit files for packages, since (at least in my opinion)
it's kind of fun.  This isn't the right place to coordinate that, but
there must be some good spot in Debian.  debian-mentors, maybe?

-- 
Russ Allbery (r...@debian.org)  

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Mon, 26 Jun 2023 at 02:05, Benda Xu  wrote:
>
> Hi Luca,
>
> Luca Boccassi  writes:
>
> >> 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
> >>
> >> 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.
>
> I take care of packages that does not meet the proposed policy. And I
> don't have a systemd test environment.  I am curious what is the
> recommended way to go forward.
>
> - upload a generator-converted .service without any test;
> - set low-NMU to encourage interested party to upload a .service;
> - leave the lack-of-systemd-service bug open until some one submit a
>   patch or a merge request;
> - you name it.

Have you already tried booting a test environment in a container
(lxc/nspawn/podman/docker) or in a VM?

Kind regards,
Luca Boccassi

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Benda Xu]

Hi Luca,

Luca Boccassi  writes:

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

I take care of packages that does not meet the proposed policy. And I
don't have a systemd test environment.  I am curious what is the
recommended way to go forward.

- upload a generator-converted .service without any test;
- set low-NMU to encourage interested party to upload a .service;
- leave the lack-of-systemd-service bug open until some one submit a
  patch or a merge request;
- you name it.

Cheers,
Benda

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 25 Jun 2023 at 19:24, Luca Boccassi  wrote:
>
> On Sun, 25 Jun 2023 at 19:21, Russ Allbery  wrote:
> >
> > Luca Boccassi  writes:
> >
> > > systemd upstream will drop support for the transitional sysv generator
> > > in the near future. The transition is long finished, it's been at least
> > > a decade, and it's time for the tail of packages still shipping only
> > > init scripts but not units to be updated.
> >
> > Has there already been a mass bug filing for packages that ship init
> > scripts but not systemd unit files?
>
> It has not, I'll get that sorted first then, thanks

Done and done:

https://lists.debian.org/debian-devel/2023/06/msg00291.html
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=missing-systemd-service

Kind regards,
Luca Boccassi

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Simon McVittie]

On Sun, 25 Jun 2023 at 18:51:24 +0100, Luca Boccassi wrote:
> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to
> depend on such a backward compat tool, so packages needing this
> hyptothetical package should depend explicitly on it.

I think it's maybe worth mentioning (not in Policy, but in the mass
bug filing about deprecating the generator) that there is an immediate
concrete benefit of moving from the generated unit to a maintainer-written
unit: it lets systemd know whether the service is meant to be a one-time
action like /etc/init.d/sudo (Type=oneshot, RemainAfterExit=yes), or
a long-running daemon like /etc/init.d/ssh (Type=forking or similar,
RemainAfterExit=no).

systemd's generator can't know which one of those each service is meant
to be (because LSB init scripts don't distinguish), so it has to make
pessimistic assumptions that work but are non-ideal in both cases.

smcv

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 25 Jun 2023 at 19:26, Ansgar  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 
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

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Ansgar]

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
+---

Ansgar

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

On Sun, 25 Jun 2023 at 19:21, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > systemd upstream will drop support for the transitional sysv generator
> > in the near future. The transition is long finished, it's been at least
> > a decade, and it's time for the tail of packages still shipping only
> > init scripts but not units to be updated.
>
> Has there already been a mass bug filing for packages that ship init
> scripts but not systemd unit files?

It has not, I'll get that sorted first then, thanks

Kind regards,
Luca Boccassi

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Luca Boccassi  writes:

> systemd upstream will drop support for the transitional sysv generator
> in the near future. The transition is long finished, it's been at least
> a decade, and it's time for the tail of packages still shipping only
> init scripts but not units to be updated.

Has there already been a mass bug filing for packages that ship init
scripts but not systemd unit files?

> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to
> depend on such a backward compat tool, so packages needing this
> hyptothetical package should depend explicitly on it. This is just
> mentioned for completeness, it's been at least a decade and writing a
> unit file is beyond trivial so there shouldn't be any issue adding the
> few remaining ones.

> Once the policy is updated I plan to ask Lintian to bump the severity
> of the existing check:

> https://salsa.debian.org/lintian/lintian/-/merge_requests/407

Assuming the mass bug filing hasn't already happened and I missed it, I
think this is the wrong order.  This sort of large-scale breaking change
should always start with a mass bug filing against all affected packages.
I think the right process is:

* Raise this in debian-devel and propose a mass bug filing requiring all
  packages to add systemd unit files if they currently only have init
  scripts.  This gives people the opportunity to object or take over
  maintenance of the unit file generator and document how to depend on it
  if they wish to do that instead.  (I don't think that's a good idea, but
  we should let the discussion happen.)

* Unless something surprising happens in that discussion, do a mass bug
  filing for this transition and bump the Lintian severity at the same
  time.

* Once that has consensus and is underway, *then* change Policy to reflect
  this project decision.

If the mass bug filing already happened and I just didn't notice, my
apologies.

-- 
Russ Allbery (r...@debian.org)  

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Luca Boccassi]

Package: debian-policy
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

systemd upstream will drop support for the transitional sysv generator
in the near future. The transition is long finished, it's been at least
a decade, and it's time for the tail of packages still shipping only
init scripts but not units to be updated.

Tentatively this should happen within Trixie's development cycle. Of
course it's free software and generators are not that difficult to
maintain, so if someone wanted to lift the sysv generator out of the
systemd repository and adapt it to be a standalone binary there's
nothing stopping them. But I wouldn't want the systemd package to
depend on such a backward compat tool, so packages needing this
hyptothetical package should depend explicitly on it. This is just
mentioned for completeness, it's been at least a decade and writing a
unit file is beyond trivial so there shouldn't be any issue adding the
few remaining ones.

Once the policy is updated I plan to ask Lintian to bump the severity
of the existing check:

https://salsa.debian.org/lintian/lintian/-/merge_requests/407

Patch attached and pushed to
https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=heads

-- 
Kind regards,
Luca Boccassi
From ea524f52d256e37b4e4747d7e6ac4f316c4805a8 Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
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 | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 207b3c0..3134783 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -328,16 +328,12 @@ Starting system services
 Introduction
 
 
-Packages that include system services should include ``systemd`` service
+Packages that include system services 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.
 
-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 including a service unit may optionally include an init script to
 support other init systems.  In this case, the init script should have the
 same name as the ``systemd`` service unit so that ``systemd`` will ignore
@@ -345,13 +341,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



signature.asc
Description: This is a digitally signed message part