Discussion:
Bug#941198: initscripts: packages should ship systemd units
Add Reply
Ansgar
2019-09-26 08:10:01 UTC
Reply
Permalink
Package: debian-policy
Version: 4.4.0.1
Severity: normal

Packages should ship systemd units as this provides a better
experience to users. (In particular the systemd-sysv-generator has to
make some assumptions that are not always correct; it is better to
explicitly tell systemd what to do.)

Ansgar
Sean Whitton
2019-09-26 22:10:02 UTC
Reply
Permalink
Hello,
Post by Ansgar
Package: debian-policy
Version: 4.4.0.1
Severity: normal
Packages should ship systemd units as this provides a better
experience to users. (In particular the systemd-sysv-generator has to
make some assumptions that are not always correct; it is better to
explicitly tell systemd what to do.)
This is a good idea.
Post by Ansgar
+Packages that include system services should include ``systemd`` units
+to start or stop services.
+
Packages that include daemons for system services should place scripts
in ``/etc/init.d`` to start or stop services at boot time or during a
change of runlevel. These scripts should be named
The text now has both "Packages that include system services ..." and
"Packages that include daemons for system services". Do you take these
to refer to different things? Surely we can combine the language somehow.
--
Sean Whitton
Ansgar
2019-09-27 07:40:02 UTC
Reply
Permalink
Post by Sean Whitton
Post by Ansgar
+Packages that include system services should include ``systemd`` units
+to start or stop services.
+
Packages that include daemons for system services should place scripts
in ``/etc/init.d`` to start or stop services at boot time or during a
change of runlevel. These scripts should be named
The text now has both "Packages that include system services ..." and
"Packages that include daemons for system services". Do you take these
to refer to different things? Surely we can combine the language somehow.
No. I just wanted to have a simple initial proposal to start with.
Arguably one can ship systemd services for more things (such as
dbus-activated or timer-activated services), but I don't think that
difference matters here.

I omitted the "daemons for" as both service files and initscripts don't
always start a persistent background process (daemon), but can also run
one-time actions.

To combine the language, maybe the second paragraph should be changed to
something like

[To support alternative init systems] packages should additionally
place initscripts in ``/etc/init.d``. These scripts should be named
...

(with or without the text in brackets).

(I think the naming rule also isn't that good: if upstream includes some
startup scripts it might be more useful to use those, even when named
differently than the package, to match upstream documentation and other
distributions.)

Ansgar
Sean Whitton
2019-09-28 15:30:04 UTC
Reply
Permalink
Hello,
Post by Ansgar
Post by Sean Whitton
Post by Ansgar
+Packages that include system services should include ``systemd`` units
+to start or stop services.
+
Packages that include daemons for system services should place scripts
in ``/etc/init.d`` to start or stop services at boot time or during a
change of runlevel. These scripts should be named
The text now has both "Packages that include system services ..." and
"Packages that include daemons for system services". Do you take these
to refer to different things? Surely we can combine the language somehow.
No. I just wanted to have a simple initial proposal to start with.
Okay.

I don't currently have any reason to doubt we have a project consensus
that systemd unit files should be included in packages in addition to
sysvinit scripts, so I hope we can make this change.
--
Sean Whitton
Russ Allbery
2019-09-29 01:20:01 UTC
Reply
Permalink
Post by Sean Whitton
I don't currently have any reason to doubt we have a project consensus
that systemd unit files should be included in packages in addition to
sysvinit scripts, so I hope we can make this change.
I agree. This seems entirely reasonable to me. Both the behavior and the
inherent documentation are better with unit files, and systemd is the
default init system so that's an advantage for a lot of our users.

That said, if anyone does object to this, please do speak up and explain
why this would be a problem.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Bill Allombert
2019-09-29 10:10:01 UTC
Reply
Permalink
Post by Russ Allbery
Post by Sean Whitton
I don't currently have any reason to doubt we have a project consensus
that systemd unit files should be included in packages in addition to
sysvinit scripts, so I hope we can make this change.
I agree. This seems entirely reasonable to me. Both the behavior and the
inherent documentation are better with unit files, and systemd is the
default init system so that's an advantage for a lot of our users.
That said, if anyone does object to this, please do speak up and explain
why this would be a problem.
There is a little technical detail that should be handled though:
User might have made change to /etc/default/xxx that is sourced
by /etc/init.d/xxx.

Such change must not be ignored by the unit files, because we require
configuration to be preserved across upgrade.

Cheers,
--
Bill. <***@debian.org>

Imagine a large red swirl here.
Josh Triplett
2019-09-29 14:40:02 UTC
Reply
Permalink
Post by Bill Allombert
Post by Russ Allbery
Post by Sean Whitton
I don't currently have any reason to doubt we have a project consensus
that systemd unit files should be included in packages in addition to
sysvinit scripts, so I hope we can make this change.
I agree. This seems entirely reasonable to me. Both the behavior and the
inherent documentation are better with unit files, and systemd is the
default init system so that's an advantage for a lot of our users.
That said, if anyone does object to this, please do speak up and explain
why this would be a problem.
User might have made change to /etc/default/xxx that is sourced
by /etc/init.d/xxx.
Such change must not be ignored by the unit files, because we require
configuration to be preserved across upgrade.
I've seen multiple packages handle this through maintainer scripts that
migrate (non-default) settings from /etc/default to a systemd drop-in or
similar configuration file.
Bill Allombert
2019-09-30 18:40:02 UTC
Reply
Permalink
Post by Josh Triplett
Post by Bill Allombert
Post by Russ Allbery
Post by Sean Whitton
I don't currently have any reason to doubt we have a project consensus
that systemd unit files should be included in packages in addition to
sysvinit scripts, so I hope we can make this change.
I agree. This seems entirely reasonable to me. Both the behavior and the
inherent documentation are better with unit files, and systemd is the
default init system so that's an advantage for a lot of our users.
That said, if anyone does object to this, please do speak up and explain
why this would be a problem.
User might have made change to /etc/default/xxx that is sourced
by /etc/init.d/xxx.
Such change must not be ignored by the unit files, because we require
configuration to be preserved across upgrade.
I've seen multiple packages handle this through maintainer scripts that
migrate (non-default) settings from /etc/default to a systemd drop-in or
similar configuration file.
Could you explain how they proceed ? That might help.

Cheers,
--
Bill. <***@debian.org>

Imagine a large red swirl here.
Russ Allbery
2019-09-29 15:10:01 UTC
Reply
Permalink
Post by Bill Allombert
Post by Russ Allbery
I agree. This seems entirely reasonable to me. Both the behavior and
the inherent documentation are better with unit files, and systemd is
the default init system so that's an advantage for a lot of our users.
That said, if anyone does object to this, please do speak up and
explain why this would be a problem.
User might have made change to /etc/default/xxx that is sourced
by /etc/init.d/xxx.
Such change must not be ignored by the unit files, because we require
configuration to be preserved across upgrade.
Yes, good call. This is partly an unrelated issue in that anyone adding a
unit file in the past also should have thought about this problem and
tackled it in some way, but we're likely to make the problem more visible
by encouraging a bunch of additional packages to add unit files.

Do you have an idea for wording to use for this?
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Dmitry Bogatov
2019-10-01 23:00:02 UTC
Reply
Permalink
Post by Russ Allbery
Post by Sean Whitton
I don't currently have any reason to doubt we have a project consensus
that systemd unit files should be included in packages in addition to
sysvinit scripts, so I hope we can make this change.
I agree. This seems entirely reasonable to me. Both the behavior and the
inherent documentation are better with unit files, and systemd is the
default init system so that's an advantage for a lot of our users.
That said, if anyone does object to this, please do speak up and explain
why this would be a problem.
Does it mean that lack of systemd unit file is RC-critical bug? Or I
will be able to waive it with "you are welcome to contribute a patch"
response?
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Russ Allbery
2019-10-01 23:10:01 UTC
Reply
Permalink
Post by Dmitry Bogatov
Does it mean that lack of systemd unit file is RC-critical bug?
No, it would be a should. So just a regular bug.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Ansgar
2019-11-01 11:30:02 UTC
Reply
Permalink
[2019-09-28 18:02] Russ Allbery
Post by Russ Allbery
I agree. This seems entirely reasonable to me. Both the behavior and the
inherent documentation are better with unit files, and systemd is the
default init system so that's an advantage for a lot of our users.
That said, if anyone does object to this, please do speak up and explain
why this would be a problem.
How to proceed with this? Do you still require any wording changes? Or
do you want to wait for the announced GR?
Does it mean that lack of systemd unit file is RC-critical bug? Or I
will be able to waive it with "you are welcome to contribute a patch"
response?
Or should we consider making shipping a sysvinit script, but no systemd
unit a RC bug? Dmitry seems to be concerned that people might just
waive it away; I don't think this needs to be a RC bug, but it might
slow adoption.

Ansgar
Simon McVittie
2019-11-01 12:30:01 UTC
Reply
Permalink
Post by Ansgar
Post by Dmitry Bogatov
Does it mean that lack of systemd unit file is RC-critical bug? Or I
will be able to waive it with "you are welcome to contribute a patch"
response?
I think in general the answer is that it should be a non-RC bug to have
an LSB ("sysvinit") init script /etc/init.d/foo without a corresponding
systemd service /lib/systemd/system/foo.service (but maintainers should
accept good patches).

Notable exceptions that shouldn't be considered to be bugs:

- if foo is provided in some other way on systemd systems, then the init
script should be masked (symlink
/lib/systemd/system/foo.service -> /dev/null), either by the package that
provides it (e.g. screen and sudo both do this), or by systemd itself
(as is currenly done for "core" init scripts in packages like sysv-rc
and x11-common; but perhaps responsibility for doing this should move
to the non-systemd package, coordinating that transition with the
systemd maintainers, now that systemd is the default and has been for
a while?)

- if foo is provided under a different name on systemd systems, then
/lib/systemd/system/foo.service should be a symlink to the
systemd name for it (udev.service -> systemd-udevd.service and
network-manager.service -> NetworkManager.service are good examples)

- packages that cannot be co-installed with systemd-sysv should get an
exemption from this, as the opposite of the rule that says it's OK that
systemd-cron doesn't have LSB init scripts :-)
Post by Ansgar
Or should we consider making shipping a sysvinit script, but no systemd
unit a RC bug?
Not in general, I don't think, but there are certainly situations where
it should be made RC on a case-by-case basis:

- rcS scripts nearly always need a native systemd service, because the units
that systemd generates for LSB init scripts always end up in the
equivalent of rc2

- more generally, if the conservative assumptions that systemd has to make
about LSB init scripts result in broken behaviour in practice (notably,
apache2 in the initial jessie release had this problem) then the broken
behaviour might be a RC bug, to be fixed by either adding a native
systemd service (like apache2 in stretch) or carefully overriding some
aspects of the generated systemd service (like apache2 in jessie updates).
In this case I'd say the absence of a systemd service is not RC, but the
*practical effect of* the absence of a systemd service can be RC.

smcv
Russ Allbery
2019-11-01 16:30:01 UTC
Reply
Permalink
Post by Ansgar
How to proceed with this? Do you still require any wording changes?
I think we can proceed to add a Policy "should" for including a systemd
unit file unless someone raises objections pretty soon here. So far, I
haven't seen any objections to the basic idea.
Post by Ansgar
Or should we consider making shipping a sysvinit script, but no systemd
unit a RC bug? Dmitry seems to be concerned that people might just
waive it away; I don't think this needs to be a RC bug, but it might
slow adoption.
Making it an RC bug seems much too aggressive to start with. We can look
at whether that makes sense later, but right now it would make far too
many packages instantly buggy.

We're doing some of that already even by introducing a "should," and
there's some argument to be made for starting with a Lintian warning
instead, but I'm not inclined to be that conservative here, mostly because
we're long-overdue for saying something, and I think the should is fairly
mild in this case.
--
Russ Allbery (***@debian.org) <https://www.eyrie.org/~eagle/>
Ansgar
2019-11-01 17:40:01 UTC
Reply
Permalink
Post by Russ Allbery
Post by Ansgar
How to proceed with this? Do you still require any wording changes?
I think we can proceed to add a Policy "should" for including a systemd
unit file unless someone raises objections pretty soon here. So far, I
haven't seen any objections to the basic idea.
Okay. Anything further I should do except wait?
Post by Russ Allbery
Post by Ansgar
Or should we consider making shipping a sysvinit script, but no systemd
unit a RC bug? Dmitry seems to be concerned that people might just
waive it away; I don't think this needs to be a RC bug, but it might
slow adoption.
Making it an RC bug seems much too aggressive to start with. We can look
at whether that makes sense later, but right now it would make far too
many packages instantly buggy.
I agree. I think it should likely stay "should" in the future anyway
(as it is currently for sysvinit too).
Post by Russ Allbery
We're doing some of that already even by introducing a "should," and
there's some argument to be made for starting with a Lintian warning
instead, but I'm not inclined to be that conservative here, mostly because
we're long-overdue for saying something, and I think the should is fairly
mild in this case.
I think there is already a lintian warning:

https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html

Ansgar
Russ Allbery
2019-11-01 18:30:02 UTC
Reply
Permalink
Post by Ansgar
Post by Russ Allbery
I think we can proceed to add a Policy "should" for including a systemd
unit file unless someone raises objections pretty soon here. So far, I
haven't seen any objections to the basic idea.
Okay. Anything further I should do except wait?
I'll take a look at the wording hopefully this weekend.
Post by Ansgar
Post by Russ Allbery
We're doing some of that already even by introducing a "should," and
there's some argument to be made for starting with a Lintian warning
instead, but I'm not inclined to be that conservative here, mostly
because we're long-overdue for saying something, and I think the should
is fairly mild in this case.
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
Oh! I should have checked rather than assuming. It would ideally be nice
to make it a warning rather than a pedantic tag before we add it to
Policy, but meh, and the count of tags isn't all that high.
--
Russ Allbery (***@debian.org) <https://www.eyrie.org/~eagle/>
Holger Levsen
2019-11-01 19:00:02 UTC
Reply
Permalink
package: lintian
severity: wishlist
version: 2.32.0
Post by Russ Allbery
Post by Ansgar
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
Oh! I should have checked rather than assuming. It would ideally be nice
to make it a warning rather than a pedantic tag before we add it to
Policy, but meh, and the count of tags isn't all that high.
I'm pretty sure this is trival and just a matter of asking via a
wishlist bug, thus doing so here.

See #941198 for more context.
--
cheers,
Holger

-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Holger Levsen
2019-11-05 02:40:01 UTC
Reply
Permalink
Post by Russ Allbery
Post by Ansgar
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
Oh! I should have checked rather than assuming. It would ideally be nice
to make it a warning rather than a pedantic tag before we add it to
Policy, but meh, and the count of tags isn't all that high.
from:

lintian (2.33.0) unstable; urgency=medium
.
[ Chris Lamb ]
* Upgrade the severity of missing-systemd-service-for-init.d-script from
pedantic to a warning. (Closes: #943957)

:)
--
cheers,
Holger

-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Russ Allbery
2019-11-03 21:10:01 UTC
Reply
Permalink
Post by Ansgar
Post by Sean Whitton
Post by Ansgar
+Packages that include system services should include ``systemd`` units
+to start or stop services.
+
Packages that include daemons for system services should place scripts
in ``/etc/init.d`` to start or stop services at boot time or during a
change of runlevel. These scripts should be named
The text now has both "Packages that include system services ..." and
"Packages that include daemons for system services". Do you take these
to refer to different things? Surely we can combine the language somehow.
No. I just wanted to have a simple initial proposal to start with.
Arguably one can ship systemd services for more things (such as
dbus-activated or timer-activated services), but I don't think that
difference matters here.
I omitted the "daemons for" as both service files and initscripts don't
always start a persistent background process (daemon), but can also run
one-time actions.
To combine the language, maybe the second paragraph should be changed to
something like
[To support alternative init systems] packages should additionally
place initscripts in ``/etc/init.d``. These scripts should be named
...
(with or without the text in brackets).
Combining this idea, I end up with this proposed change:

--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -388,11 +388,14 @@ argument ``stop``.
Writing the scripts
~~~~~~~~~~~~~~~~~~~

-Packages that include daemons for system services should place scripts
-in ``/etc/init.d`` to start or stop services at boot time or during a
-change of runlevel. These scripts should be named
-``/etc/init.d/package``, and they should accept one argument, saying
-what to do:
+Packages that include system services should include ``systemd`` service
+units to start or stop those services. See :manpage:`systemd.service(5)`.
+
+To support other init systems, packages that include daemons for system
+services should place scripts in ``/etc/init.d`` to start or stop those
+services at boot time or during a change of runlevel. These scripts should
+be named ``/etc/init.d/package``, and they should accept one argument,
+saying what to do:

``start``
start the service,

Ansgar, does that look good to you? If so, it also needs one more second.
--
Russ Allbery (***@debian.org) <https://www.eyrie.org/~eagle/>
Sean Whitton
2019-11-07 07:20:01 UTC
Reply
Permalink
Hello,
Post by Russ Allbery
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -388,11 +388,14 @@ argument ``stop``.
Writing the scripts
~~~~~~~~~~~~~~~~~~~
-Packages that include daemons for system services should place scripts
-in ``/etc/init.d`` to start or stop services at boot time or during a
-change of runlevel. These scripts should be named
-``/etc/init.d/package``, and they should accept one argument, saying
+Packages that include system services should include ``systemd`` service
+units to start or stop those services. See :manpage:`systemd.service(5)`.
+
+To support other init systems, packages that include daemons for system
+services should place scripts in ``/etc/init.d`` to start or stop those
+services at boot time or during a change of runlevel. These scripts should
+be named ``/etc/init.d/package``, and they should accept one argument,
``start``
start the service,
Seconded.
--
Sean Whitton
Ansgar
2019-11-08 01:00:01 UTC
Reply
Permalink
Post by Russ Allbery
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -388,11 +388,14 @@ argument ``stop``.
Writing the scripts
~~~~~~~~~~~~~~~~~~~
-Packages that include daemons for system services should place scripts
-in ``/etc/init.d`` to start or stop services at boot time or during a
-change of runlevel. These scripts should be named
-``/etc/init.d/package``, and they should accept one argument, saying
+Packages that include system services should include ``systemd`` service
+units to start or stop those services. See :manpage:`systemd.service(5)`.
+
+To support other init systems, packages that include daemons for system
+services should place scripts in ``/etc/init.d`` to start or stop those
+services at boot time or during a change of runlevel. These scripts should
+be named ``/etc/init.d/package``, and they should accept one argument,
``start``
start the service,
Ansgar, does that look good to you? If so, it also needs one more second.
Yes, looks good to me. Seconded.

Thanks,
Ansgar
Adam Borowski
2019-12-01 17:10:02 UTC
Reply
Permalink
Hi!
This idea being discussed hasn't been announced anywhere. And, it's
extremely harmful to the support of anything non-systemd, while providing
very little if any benefit to systemd users as well. It also would cause
doubling of maintainer effort.

But, in the light of the ongoing GR, arguing would be a waste of time at
this moment. Thus, could you please put this change into abeyance, and
once the GR is finished, we'll discuss whether to withdraw (or even reverse,
it should be "should not"!), according to the GR's result.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄⠀⠀⠀⠀ etc), let the drink age at least 3-6 months.
Sean Whitton
2019-12-01 17:40:01 UTC
Reply
Permalink
Hello Adam,
Post by Adam Borowski
This idea being discussed hasn't been announced anywhere. And, it's
extremely harmful to the support of anything non-systemd, while providing
very little if any benefit to systemd users as well. It also would cause
doubling of maintainer effort.
But, in the light of the ongoing GR, arguing would be a waste of time at
this moment. Thus, could you please put this change into abeyance, and
once the GR is finished, we'll discuss whether to withdraw (or even reverse,
it should be "should not"!), according to the GR's result.
I'm afraid I fail to see how this bug interacts with the current GR at
all. It seems to me that it could interact with the current GR only if
the current GR was about changing the default init system, but no-one is
proposing anything like that.

How do you think this bug is prejudicial to advocates of alternative
init systems?

At any rate, we're unlikely to do a normative Policy release before
voting is done because we usually wait until we have more than two
normative changes waiting on our 'next' branch before doing that.
--
Sean Whitton
Ansgar
2019-12-02 09:30:01 UTC
Reply
Permalink
Post by Adam Borowski
This idea being discussed hasn't been announced anywhere. And, it's
extremely harmful to the support of anything non-systemd, while providing
very little if any benefit to systemd users as well. It also would cause
doubling of maintainer effort.
How would provide systemd service files be extremely harmful for
anything non-systemd?

Is providing sysvinit scripts extremely harmful for anything
non-sysvinit?

Was providing upstart jobs extremely harmful for anything non-upstart?

Would providing runit jobs be extremely harmful for anything non-runit?
Post by Adam Borowski
But, in the light of the ongoing GR, arguing would be a waste of time at
this moment. Thus, could you please put this change into abeyance, and
once the GR is finished, we'll discuss whether to withdraw (or even reverse,
it should be "should not"!), according to the GR's result.
I assume you think that packages that provide sysvinit script *should*
*not* ship OpenRC, runit or any other non-sysvinit support either?

That would make any init system in Debian a wrapper around starting
sysvinit script which seems a bit boring and blocking any innovation to
me. Though I think it might be close to what runit or OpenRC support
currently means in Debian.

Ansgar
Russ Allbery
2019-12-02 21:00:02 UTC
Reply
Permalink
Post by Ansgar
That would make any init system in Debian a wrapper around starting
sysvinit script which seems a bit boring and blocking any innovation to
me. Though I think it might be close to what runit or OpenRC support
currently means in Debian.
I don't believe this is the approach being taken by runit. They've
introduced a handful of *-run packages to start as daemon with runit
instead, and I think some other packages just ship the runit integration
directly in the package.

If runit works the way that I believe that it does, it will similarly do
much better with dedicated configuration than with trying to run sysvinit
scripts for some of the same reasons as systemd. For instance, it would
much prefer if services didn't background themselves and instead stayed in
the foreground so that they could be more easily monitored.
--
Russ Allbery (***@debian.org) <https://www.eyrie.org/~eagle/>
Sean Whitton
2019-12-01 23:30:02 UTC
Reply
Permalink
Hello,
I don't think there's any urgent need to put out a new normative version
of Policy and we could hold the next release until January. What do you
think, Sean?
I'd be happy with an informal hold on normative releases, but before we
commit to that, I'd like to hear Adam explain how he thinks the GR
interacts with the bug at all, because so far as I can tell they're
orthogonal.
--
Sean Whitton
Simon Richter
2019-12-04 18:20:01 UTC
Reply
Permalink
Hi,

chiming in as I've been pointed to this bug: I agree with Ansgar in that
adding unit files does not hurt sysvinit support in the least, provided we
still get to ignore them.

I'd even be in favour of making them mandatory (i.e. upgrading the lintian
warning to an error), and I don't see how the GR outcome would affect the
question of whether we want to ship unit files in packages, so I'd be fine
with going ahead with this change even while the GR is still running.

As long as we support sysv-rc, init scripts will have to remain mandatory
as well, though.

IMO, an ideal outcome would be that systemd can completely ignore any init
scripts from Debian packages, i.e. the compatibility generator, if
installed, would only have to generate units for init scripts that didn't
come from a package, and default installations would not include this
generator.

The same should be done for cron files vs timer units -- ideally, we'd get
to a state where cron files can be completely ignored by systemd because it
is a bug to not have a timer unit with the same settings. That would allow
systemd users to get rid of the spurious wakeups as well, which I'd
consider a major win.

Simon
Tobias Frost
2019-12-08 01:10:02 UTC
Reply
Permalink
Post by Simon Richter
Hi,
chiming in as I've been pointed to this bug: I agree with Ansgar in that
adding unit files does not hurt sysvinit support in the least, provided we
still get to ignore them.
I'd even be in favour of making them mandatory (i.e. upgrading the lintian
warning to an error), and I don't see how the GR outcome would affect the
question of whether we want to ship unit files in packages, so I'd be fine
with going ahead with this change even while the GR is still running.
As long as we support sysv-rc, init scripts will have to remain mandatory
as well, though.
IMO, an ideal outcome would be that systemd can completely ignore any init
scripts from Debian packages, i.e. the compatibility generator, if
installed, would only have to generate units for init scripts that didn't
come from a package, and default installations would not include this
generator.
JFTR, I maintain gmedia-resurrect and in this package I failed despite trying
to create a systemd unit file with equal functinality as the init.d script*.
So for this package the proposoal would lead to regressions for the users.
Post by Simon Richter
The same should be done for cron files vs timer units -- ideally, we'd get
to a state where cron files can be completely ignored by systemd because it
is a bug to not have a timer unit with the same settings. That would allow
systemd users to get rid of the spurious wakeups as well, which I'd
consider a major win.
Simon
* I do not have currently the amount of spoons avialable to explain the details,
but it has to do with the confile in /etc/default needed to be read by the unit
file and parsed into daemon parameters.
Russ Allbery
2019-12-08 01:20:01 UTC
Reply
Permalink
Post by Tobias Frost
JFTR, I maintain gmedia-resurrect and in this package I failed despite
trying to create a systemd unit file with equal functinality as the
init.d script*. So for this package the proposoal would lead to
regressions for the users.
A Policy should means that if there is some stronger reason (such as that
adding a unit file would introduce new bugs), there is nothing requiring
you to do so. It indicates that not having a unit file is a bug, but it's
just a bug, and Debian packages are not expected to be bug-free. Other
bugs may be more important.

That said, if you'd like help with this, I or someone else following this
thread may be willing to take a look and figure out a way to replicate the
init script behavior. It's normally possible to handle /etc/default
conffiles in systemd units, although it can be a little complicated.
--
Russ Allbery (***@debian.org) <https://www.eyrie.org/~eagle/>
Tobias Frost
2019-12-08 09:40:01 UTC
Reply
Permalink
Post by Russ Allbery
Post by Tobias Frost
JFTR, I maintain gmedia-resurrect and in this package I failed despite
trying to create a systemd unit file with equal functinality as the
init.d script*. So for this package the proposoal would lead to
regressions for the users.
A Policy should means that if there is some stronger reason (such as that
adding a unit file would introduce new bugs), there is nothing
requiring
you to do so. It indicates that not having a unit file is a bug, but it's
just a bug, and Debian packages are not expected to be bug-
free. Other
bugs may be more important.
Well, I was responding to a mail that suggested to make unit files
mandatory (which I read as then RC-buggy) and suggesting some lines
later to drop support for the sysv-generator and in this case it is
quite moot that policy can be ignored because I fear that once
unit files would become mandatory that would be used as an argument to
drop support for the generator.
Post by Russ Allbery
That said, if you'd like help with this, I or someone else following this
thread may be willing to take a look and figure out a way to
replicate the
init script behavior. It's normally possible to handle /etc/default
conffiles in systemd units, although it can be a little complicated.
Sure, help fir that would be nice. Thanks for the offer.
(Probably should have an own bug for that.) Nethertheless, this is the
line that causes my problems and needs to be transferred:
https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8

-- tobi
Russ Allbery
2019-12-08 19:20:01 UTC
Reply
Permalink
Post by Tobias Frost
Post by Russ Allbery
A Policy should means that if there is some stronger reason (such as
that adding a unit file would introduce new bugs), there is nothing
requiring you to do so. It indicates that not having a unit file is a
bug, but it's just a bug, and Debian packages are not expected to be
bug- free. Other bugs may be more important.
Well, I was responding to a mail that suggested to make unit files
mandatory (which I read as then RC-buggy) and suggesting some lines
later to drop support for the sysv-generator and in this case it is
quite moot that policy can be ignored because I fear that once unit
files would become mandatory that would be used as an argument to drop
support for the generator.
Just to be clear, that's not what this bug proposes. This bug just
proposes making systemd unit files recommended.
Post by Tobias Frost
Sure, help fir that would be nice. Thanks for the offer. (Probably
should have an own bug for that.) Nethertheless, this is the line that
https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
Ah, I see, the problem is the $(hostname) part, which isn't supported by
EnvironmentFile in systemd (which is the normal way to solve this
problem).

After looking at this for a bit, my inclination if I were you would be to
write a tiny shell script that loads /etc/default/gmediarender, constructs
the command line, and then execs the daemon; install that script as
/usr/share/gmediarender/start; and then invoke that script via
start-stop-daemon in the init script and via ExecStart in the systemd unit
file. It's a little bit overkill because most of what the /etc/default
file is doing is simple, but it looks like the easiest way to handle
$(hostname).
--
Russ Allbery (***@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover
2019-12-08 22:40:01 UTC
Reply
Permalink
Post by Russ Allbery
Post by Tobias Frost
Sure, help fir that would be nice. Thanks for the offer. (Probably
should have an own bug for that.) Nethertheless, this is the line that
https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
Ah, I see, the problem is the $(hostname) part, which isn't supported by
EnvironmentFile in systemd (which is the normal way to solve this
problem).
After looking at this for a bit, my inclination if I were you would be to
write a tiny shell script that loads /etc/default/gmediarender, constructs
the command line, and then execs the daemon; install that script as
/usr/share/gmediarender/start; and then invoke that script via
start-stop-daemon in the init script and via ExecStart in the systemd unit
file. It's a little bit overkill because most of what the /etc/default
file is doing is simple, but it looks like the easiest way to handle
$(hostname).
I'd avoid using the wrapper for the init script TBH, because even
though that will make this a bit WET, it would otherwise make it more
complex there (having to use --startas and --exec to cope with the
intermediate interpreter usage).

I think shared wrappers make more sense when used to offload some kind of
pre/post "hook" work, which gets called from Exec{Start,Stop}{Pre,Post}
systemd service file directives (and init scripts).

But here you do have another option, but I'm not sure it might be
described as nicer TBH, :) something like this, or variations on this
theme:

[Service]
Type=simple
EnvironmentFile=/etc/default/service-static-vars
EnvironmentFile=-/run/service-dynamic-vars
ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) >/run/service-dynamic-vars'
ExecStart=/usr/bin/daemon --option ${NAME}

Thanks,
Guillem
Russ Allbery
2019-12-09 00:00:02 UTC
Reply
Permalink
Post by Guillem Jover
But here you do have another option, but I'm not sure it might be
described as nicer TBH, :) something like this, or variations on this
[Service]
Type=simple
EnvironmentFile=/etc/default/service-static-vars
EnvironmentFile=-/run/service-dynamic-vars
ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) >/run/service-dynamic-vars'
ExecStart=/usr/bin/daemon --option ${NAME}
This is a nice approach, but I don't think it quite preserves the original
behavior. As you wrote it above, if someone changed the setting in the
/etc/default file, that would have no effect and the default would still
be used. If you reverse the order of EnvironmentFile, it avoids that
problem, but now the legacy setting with $(hostname) will be used if it
hasn't been changed, and that will result in a literal $(hostname) in the
value.
--
Russ Allbery (***@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover
2019-12-09 00:50:01 UTC
Reply
Permalink
Post by Russ Allbery
Post by Guillem Jover
But here you do have another option, but I'm not sure it might be
described as nicer TBH, :) something like this, or variations on this
[Service]
Type=simple
EnvironmentFile=/etc/default/service-static-vars
EnvironmentFile=-/run/service-dynamic-vars
ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) >/run/service-dynamic-vars'
ExecStart=/usr/bin/daemon --option ${NAME}
This is a nice approach, but I don't think it quite preserves the original
behavior. As you wrote it above, if someone changed the setting in the
/etc/default file, that would have no effect and the default would still
be used. If you reverse the order of EnvironmentFile, it avoids that
problem, but now the legacy setting with $(hostname) will be used if it
hasn't been changed, and that will result in a literal $(hostname) in the
value.
Right, it was more about showing the concept than a proper
implementation, but it's true that as is, it's not helpful. :)

I guess the following which starts to get a bit into ugly territory
would do instead:

[Service]
Type=simple
EnvironmentFile=-/run/service-dynamic-vars
ExecStartPre=-/usr/bin/env -i /bin/sh -a -c '. /etc/default/service-static-vars && env -uPWD >/run/service-dynamic-vars'
ExecStart=/usr/bin/daemon --option ${NAME}

Thanks,
Guillem

Bill Allombert
2019-12-08 12:20:02 UTC
Reply
Permalink
Post by Russ Allbery
That said, if you'd like help with this, I or someone else following this
thread may be willing to take a look and figure out a way to replicate the
init script behavior. It's normally possible to handle /etc/default
conffiles in systemd units, although it can be a little complicated.
If possible, this should be made simple.

Package are supposed to preserve user configuration across upgrade,
so unit files should not simply ignore user change to /etc/default.

Cheers,
--
Bill. <***@debian.org>

Imagine a large red swirl here.
Bill Allombert
2019-12-08 13:30:02 UTC
Reply
Permalink
Post by Tobias Frost
Sure, help fir that would be nice. Thanks for the offer.
(Probably should have an own bug for that.) Nethertheless, this is the
https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
I think they way forward is getting rid of .default files. These options
belong in software specific conffiles, not in conffiles for initscript
conffiles.
I disagree. The command line / environment is a perfectly valid way to
set software options. It has a standard and well-understood interface,
while each configuration files tend to have their own unique syntax and
parser idiosynchrasy and bogosity. We should have less configuration
file parsers, not more.

In any case, this is an upstream choice, not a packaging choice, so we
have to use what upstream provide.

Cheers,
--
Bill. <***@debian.org>

Imagine a large red swirl here.
Andrey Rahmatullin
2019-12-08 14:10:01 UTC
Reply
Permalink
Post by Bill Allombert
Post by Tobias Frost
Sure, help fir that would be nice. Thanks for the offer.
(Probably should have an own bug for that.) Nethertheless, this is the
https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
I think they way forward is getting rid of .default files. These options
belong in software specific conffiles, not in conffiles for initscript
conffiles.
I disagree. The command line / environment is a perfectly valid way to
set software options. It has a standard and well-understood interface,
while each configuration files tend to have their own unique syntax and
parser idiosynchrasy and bogosity. We should have less configuration
file parsers, not more.
In that case users should edit the unit files directly, configuring the
command directly.
--
WBR, wRAR
David Bremner
2019-12-08 17:10:01 UTC
Reply
Permalink
Post by Bill Allombert
In any case, this is an upstream choice, not a packaging choice, so we
have to use what upstream provide.
Just to be clear using /etc/default is not an upstream choice, it's a
Debian convention. I know you probably didn't mean to imply that, but
that's how it read to me.

d
Bill Allombert
2019-12-08 17:20:01 UTC
Reply
Permalink
Post by David Bremner
Post by Bill Allombert
In any case, this is an upstream choice, not a packaging choice, so we
have to use what upstream provide.
Just to be clear using /etc/default is not an upstream choice, it's a
Debian convention. I know you probably didn't mean to imply that, but
that's how it read to me.
The context is that some package are configured via setting some
environment variable or command line parameter instead of reading a
config file at start up, and this is precisely the situation when
/etc/default is used.

I argue that whether to use command line parameters or to read a config
file is an upstream choice.

Cheers,
--
Bill. <***@debian.org>

Imagine a large red swirl here.
Loading...