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

[Luca Boccassi]

On Sun, 25 Jun 2023 at 19:21, Russ Allbery <r...@debian.org> wrote:
>
> Luca Boccassi <bl...@debian.org> 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

[Russ Allbery]

Luca Boccassi <bl...@debian.org> 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) <https://www.eyrie.org/~eagle/>

[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

[Luca Boccassi]

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

[Benda Xu]

Hi Luca,

Luca Boccassi <bl...@debian.org> 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

[Luca Boccassi]

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

Kind regards,
Luca Boccassi

[Russ Allbery]

Benda Xu <her...@gentoo.org> 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?

[Benda Xu]

Luca Boccassi <bl...@debian.org> 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 <r...@debian.org> 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

[Luca Boccassi]

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

[Luca Boccassi]

On Fri, 30 Jun 2023 00:04:29 +0100 Luca Boccassi <bl...@debian.org>
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?

[Bill Allombert]

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. <ball...@debian.org>

Imagine a large red swirl here.

[Luca Boccassi]

On Sun, 30 Jul 2023 23:12:21 +0200 Bill Allombert <ball...@debian.org>
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 <bl...@debian.org>
> > 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.

[Sam Hartman]

>>>>> "Luca" == Luca Boccassi <bl...@debian.org> 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.)

[Russ Allbery]

Luca Boccassi <bl...@debian.org> 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]

Russ Allbery <r...@debian.org> 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 Boccassi]

Thank you, looks good to me, seconded.

[Sam Hartman]

>>>>> "Luca" == Luca Boccassi <bl...@debian.org> writes:

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

LGTM too, seconded.

[Edward Little]

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

[Russ Allbery]

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

[Luca Boccassi]

On Tue, 12 Sep 2023, 06:13 Russ Allbery, <r...@debian.org> wrote:

Sam Hartman <hart...@debian.org> writes:
>>>>>> "Luca" == Luca Boccassi <bl...@debian.org> 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!