Is it the job of Lintian to push an agenda?

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Is it the job of Lintian to push an agenda?

Vincent Bernat-3
Hey!

Lintian got a new tag to enforce Policy 9.11:

 Packages may integrate with these replacement init systems by
 providing implementation-specific configuration information
 about how and when to start a service or in what order to run
 certain tasks at boot time. However, any package integrating
 with other init systems must also be backwards-compatible with
 sysvinit by providing a SysV- style init script with the same
 name as and equivalent functionality to any init-specific job,
 as this is the only start-up configuration method guaranteed to
 be supported by all init implementations.

Lintian tag:
 <https://lintian.debian.org/tags/package-supports-alternative-init-but-no-init.d-script.html>

This tag has false positives, see:
 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931889>

Original bug introducing this tag is:
 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926471>

The policy update is being discussed here:
 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911165>

As usual with a policy change, it will take years. Some people will push
back and the result is that a few people can impose to everyone else the
additional work to maintain SysV init script.

Previously, we had a sort of agreement (through the TC decision) that
such scripts should be maintained by people caring about them and we
should only act on bug reports with proper patches to have them. Thanks
to this new Lintian tag, the current situation is that packages won't
pass NEW without a SysV init script (unless a FTP-masters ignore this
specific tag despite its severity).

This Lintian tag was introduced by the maintainer of runit in a clear
attempt to push more work towards people not shipping SysV init script.
Could it be just reverted on the ground of the TC statement and the fact
that systemd is not an alternative init?
--
Zounds!  I was never so bethumped with words
since I first called my brother's father dad.
                -- William Shakespeare, "Kind John"

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Russ Allbery-2
Vincent Bernat <[hidden email]> writes:

> Lintian got a new tag to enforce Policy 9.11:

>  Packages may integrate with these replacement init systems by
>  providing implementation-specific configuration information
>  about how and when to start a service or in what order to run
>  certain tasks at boot time. However, any package integrating
>  with other init systems must also be backwards-compatible with
>  sysvinit by providing a SysV- style init script with the same
>  name as and equivalent functionality to any init-specific job,
>  as this is the only start-up configuration method guaranteed to
>  be supported by all init implementations.

Policy 9.11 and this provision were introduced in Policy 3.9.4, which was
published in August of 2012.  I'm therefore very confused by this
statement:

> As usual with a policy change, it will take years.

since this is not a recent Policy change (in fact, prior to this section
of Policy there was no documentation of support for any init system
*other* than sysvinit), and it's *been* years.  So far as I can tell, the
only thing that's new is the Lintian tag.  Lintian aspires to testing as
much of Policy as possible, so my baseline assumption would be that
someone contributing to Lintian just got around to doing the
implementation work.

The Policy provision is, as you noted in the bug references I snipped,
arguably buggy in that it doesn't clarly allow for systemd units that
should not or cannot correspond to init scripts, and it could definitely
use some tweaking (as, possibly, could the Lintian tag), but the base
requirement for providing a corresponding sysvinit init script to start a
daemon that is started via a systemd unit file is not new and has been the
Policy requirement since before systemd became the default init system.

> Some people will push back and the result is that a few people can
> impose to everyone else the additional work to maintain SysV init
> script.

Continued support for sysvinit has been the consensus of the project since
the systemd debate.  We can, of course, change that, but *that* would be
the change, not this.

> Previously, we had a sort of agreement (through the TC decision) that
> such scripts should be maintained by people caring about them and we
> should only act on bug reports with proper patches to have them.

I don't agree that this was ever the agreement.

> Thanks to this new Lintian tag, the current situation is that packages
> won't pass NEW without a SysV init script (unless a FTP-masters ignore
> this specific tag despite its severity).

I haven't worked on Lintian in several years, so perhaps my information is
stale, but at least previously ftp-master rejects were not based on
severity, but rather on a hard-coded list of tags maintained by
ftp-master.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Scott Kitterman-5
On Saturday, July 13, 2019 2:52:59 PM EDT Russ Allbery wrote:
> Vincent Bernat <[hidden email]> writes:
> > Thanks to this new Lintian tag, the current situation is that packages
> > won't pass NEW without a SysV init script (unless a FTP-masters ignore
> > this specific tag despite its severity).
>
> I haven't worked on Lintian in several years, so perhaps my information is
> stale, but at least previously ftp-master rejects were not based on
> severity, but rather on a hard-coded list of tags maintained by
> ftp-master.

That's correct.  We do also do a general review of the package and lintian
feedback is one thing we do consider.  Personally, I don't recall having
rejected a package for this.  I believe I have accepted a few and then filed a
bug (even prior to the lintian check).

Scott K


Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Niels Thykier
In reply to this post by Russ Allbery-2
Russ Allbery:
>> Thanks to this new Lintian tag, the current situation is that packages
>> won't pass NEW without a SysV init script (unless a FTP-masters ignore
>> this specific tag despite its severity).
> I haven't worked on Lintian in several years, so perhaps my information is
> stale, but at least previously ftp-master rejects were not based on
> severity, but rather on a hard-coded list of tags maintained by
> ftp-master.

For reference, Russ is correct.  For the people curious about the
concrete tags, please see [1].

Thanks,
~Niels

[1] https://ftp-master.debian.org/#lintianrejects

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Vincent Bernat-3
In reply to this post by Russ Allbery-2
 ❦ 13 juillet 2019 11:52 -07, Russ Allbery <[hidden email]>:

>> Previously, we had a sort of agreement (through the TC decision) that
>> such scripts should be maintained by people caring about them and we
>> should only act on bug reports with proper patches to have them.
>
> I don't agree that this was ever the agreement.

I was referring to
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715> but it seems
it only applies to non-SysV init script, my bad.

I am still unhappy with the situation, but I don't think it is worth
arguing about it as I am pretty sure it will have no impact whatsoever.
--
Modularise.  Use subroutines.
            - The Elements of Programming Style (Kernighan & Plauger)

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Matthias Klumpp-2
Am Sa., 13. Juli 2019 um 22:04 Uhr schrieb Vincent Bernat <[hidden email]>:

>
>  ❦ 13 juillet 2019 11:52 -07, Russ Allbery <[hidden email]>:
>
> >> Previously, we had a sort of agreement (through the TC decision) that
> >> such scripts should be maintained by people caring about them and we
> >> should only act on bug reports with proper patches to have them.
> >
> > I don't agree that this was ever the agreement.
>
> I was referring to
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715> but it seems
> it only applies to non-SysV init script, my bad.
>
> I am still unhappy with the situation, but I don't think it is worth
> arguing about it as I am pretty sure it will have no impact whatsoever.

What will have an impact is moving
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911165> forward, I
guess.
Writing init scripts for sysvinit is a massive amount of work for
non-simple cases, and my own software as well as other software
projects don't actually ship sysvinit scripts anymore (simply because
testing them just isn't worth the time and effort if you can actually
achieve what you wanted easier).
While I think it's fair to request from package maintainers to merge
compatibility scripts for sysvinit, forcing them to write sysvinit
scripts while our default init systemd is systemd and where even
testing those scripts is a major pain is IMHO not.
There was a long discussion on not-shipping / dropping sysvinit
scripts in a request to the TC in 2016
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835507>, I am
assuming you meant that when talking about a TC ruling. No decision
was made there though, and normal policy processes should resolve
this.
With two Debian stable releases defaulting to systemd now, I think a
solid case could be made to at least relax the "must" requirement to a
"should" in policy (but that should better go to the respective bug
report).

Cheers,
    Matthias

--
I welcome VSRE emails. See http://vsre.info/

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Jérémy Lal-2
In reply to this post by Vincent Bernat-3
Hi,

the question
"Is it the job of Lintian to push an agenda?"
is a good question, and it would be nice to get a general answer,
separately from the technical issue about sysvinit scripts.

Jérémy
Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Russ Allbery-2
In reply to this post by Matthias Klumpp-2
Matthias Klumpp <[hidden email]> writes:

> With two Debian stable releases defaulting to systemd now, I think a
> solid case could be made to at least relax the "must" requirement to a
> "should" in policy (but that should better go to the respective bug
> report).

The Policy process is not equipped to deal with this because that process
requires fairly consensus, and I don't believe that's possible to reach on
this topic.

I don't know what decision-making process the project should use here: a
big thread on debian-devel (wow, that sounds fun), a bunch of in-person
conversations at DebConf (probably way more productive but excludes some
folks), the TC (tried and didn't work very well), a GR, some new mediated
consensus process, or what.  Or maybe some working group that goes all-in
on creating a "good enough" automated translation from unit files to
sysvinit scripts and we support sysvinit that way and thereby dodge the
problem.

But, and I'm putting my Policy Editor delegate hat on to say this, I
believe the Policy process is the wrong tool to use here because it will
not converge.  (That said, Sean, as the other Policy Editor delegate,
should feel free to disagree if he thinks I'm wrong.)

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Russ Allbery-2
Russ Allbery <[hidden email]> writes:

> The Policy process is not equipped to deal with this because that
> process requires fairly consensus, and I don't believe that's possible
> to reach on this topic.

Argh.  That should have been "fairly strong consensus" and fell victim to
last-minute editing.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Sean Whitton
In reply to this post by Russ Allbery-2
Hello,

On Sat 13 Jul 2019 at 02:22PM -07, Russ Allbery wrote:

> Matthias Klumpp <[hidden email]> writes:
>
>> With two Debian stable releases defaulting to systemd now, I think a
>> solid case could be made to at least relax the "must" requirement to a
>> "should" in policy (but that should better go to the respective bug
>> report).
>
> The Policy process is not equipped to deal with this because that process
> requires fairly consensus, and I don't believe that's possible to reach on
> this topic.
>
> I don't know what decision-making process the project should use here: a
> big thread on debian-devel (wow, that sounds fun), a bunch of in-person
> conversations at DebConf (probably way more productive but excludes some
> folks), the TC (tried and didn't work very well), a GR, some new mediated
> consensus process, or what.  Or maybe some working group that goes all-in
> on creating a "good enough" automated translation from unit files to
> sysvinit scripts and we support sysvinit that way and thereby dodge the
> problem.
>
> But, and I'm putting my Policy Editor delegate hat on to say this, I
> believe the Policy process is the wrong tool to use here because it will
> not converge.  (That said, Sean, as the other Policy Editor delegate,
> should feel free to disagree if he thinks I'm wrong.)
Just to note that I'm in agreement with Russ on this.  While things may
well change in the future (either the project's opinion on init or the
way Policy works), Policy is not the way to do this for the time being.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Sean Whitton
In reply to this post by Jérémy Lal-2
Hello,

On Sat 13 Jul 2019 at 11:10PM +02, Jérémy Lal wrote:

> the question
> "Is it the job of Lintian to push an agenda?"
> is a good question, and it would be nice to get a general answer,
> separately from the technical issue about sysvinit scripts.

I think that it is useful to Debian for Lintian to be a bit more
opinionated, and a bit less conservative, than Policy is.

Especially if you turn on all the tag levels, Lintian pushes a fairly
strong set of ideas about what packages should look like.  Most everyone
will find something they disagree with, but it gets us to think about
these things and consider whether they might be good ideas.  Over time,
tags can get turned down in severity or changes can make their way into
the Policy Manual.

Of course, if Lintian gets too far "ahead" of Policy then it would be
less useful.  What I think is useful to us is for it to be just a little
bit more pushy than Policy, as indeed it is.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Ansgar Burchardt-8
In reply to this post by Russ Allbery-2
Russ Allbery writes:
> Matthias Klumpp writes:
>> With two Debian stable releases defaulting to systemd now, I think a
>> solid case could be made to at least relax the "must" requirement to a
>> "should" in policy (but that should better go to the respective bug
>> report).
>
> The Policy process is not equipped to deal with this because that process
> requires fairly consensus, and I don't believe that's possible to reach on
> this topic.

If we have no consensus that doing something is the right thing, then
lintian should probably not start raising a warning about it and one
should keep in mind that Policy might not reflect consensus when
referring to it.

Ansgar

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Sam Hartman-3
>>>>> "Ansgar" == Ansgar Burchardt <[hidden email]> writes:

    Ansgar> Russ Allbery writes:
    >> Matthias Klumpp writes:
    >>> With two Debian stable releases defaulting to systemd now, I
    >>> think a solid case could be made to at least relax the "must"
    >>> requirement to a "should" in policy (but that should better go
    >>> to the respective bug report).
    >>
    >> The Policy process is not equipped to deal with this because that
    >> process requires fairly consensus, and I don't believe that's
    >> possible to reach on this topic.

    Ansgar> If we have no consensus that doing something is the right
    Ansgar> thing, then lintian should probably not start raising a
    Ansgar> warning about it and one should keep in mind that Policy
    Ansgar> might not reflect consensus when referring to it.

When the policy decision was made, I think we did have consensus.

So, no, that's our current policy at least until something changes it.
The processes I'm aware of for changing policy absent a consensus to do
so are GR and TC.

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Theodore Y. Ts'o
In reply to this post by Russ Allbery-2
On Sat, Jul 13, 2019 at 02:22:01PM -0700, Russ Allbery wrote:

> Matthias Klumpp <[hidden email]> writes:
>
> > With two Debian stable releases defaulting to systemd now, I think a
> > solid case could be made to at least relax the "must" requirement to a
> > "should" in policy (but that should better go to the respective bug
> > report).
>
> The Policy process is not equipped to deal with this because that process
> requires fairly consensus, and I don't believe that's possible to reach on
> this topic.
>
> I don't know what decision-making process the project should use here: a
> big thread on debian-devel (wow, that sounds fun), a bunch of in-person
> conversations at DebConf (probably way more productive but excludes some
> folks), the TC (tried and didn't work very well), a GR, some new mediated
> consensus process, or what.  Or maybe some working group that goes all-in
> on creating a "good enough" automated translation from unit files to
> sysvinit scripts and we support sysvinit that way and thereby dodge the
> problem.

The alternative seems to be a large number of package maintainers
willfuly ignoring a particular reading of the Policy, whether or not
that reading of the policy is "correct" or not.  Hopefully we can
avoid bug priority escalation/descalation wars over what might or
might not be a policy violation.   Oh joy....

                                        - Ted

P.S.  I'm going to be adding an override in e2fsprogs for
package-supports-alternative-init-but-no-init.d-script because it
has false positive, regardless of its claim:

N:    Severity: important, Certainty: certain

It most *definitely* is not certain.  We went through quite a bit of
trouble providing alternative functionality via cron, and not via
(only) systemd timers.  I will admit the functionality is slightly
better if you are using systemd, but as saying goes, "patches
gratefully accepted".  Whining for developers to do extra work via
Debian Policy is, well, not.

And I say all of this not being a systemd fan.  But the vast majority
of Linux ecosystem has made a choice, and we should just move *on*.

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Chris Lamb -2
In reply to this post by Jérémy Lal-2
Jérémy Lal wrote:

> "Is it the job of Lintian to push an agenda?"
> is a good question, and it would be nice to get a general answer,
> separately from the technical issue about sysvinit scripts.

Difficulties are always inherent in shipping any opinionated linter to
people with a wide spectrum of motivations and ideas. Furthermore, if
it becomes pervasive then there is not only a risk of its output being
followed without attention, when interpreted as a kind of de-facto
policy there is an additional a danger of it being beaten from a
plowshare back into a sword on contentious issues.

As the first line of defense to the above, Lintian reflects the
positions taken and espoused in our official Policy and should [0]
always defer to that esteemed text.

It therefore follows that if the Debian Policy decrees a certain
direction and Lintian mirrors that then in the rare cases of dissent
or disagreement the right and proper course of action is to re-raise
it via Policy and its various appeal processes. If that is not
possible then that is a regrettable state of affairs, but Lintian is
not the venue to stage one's passive-aggressive proxy war on
controversial and highly-charged issues within Debian and its
maintainers have neither the strength, stomach nor spoons for such
maneuevers.

As Sean implies in an adjacent message, all of the above is compounded
by there being a number of recommendations that are considered to be
good practice by most [1] but are not part of Policy (and most should
or can never be). Lintian's various severity levels ("E:", "W:", "I:",
etc), as well as responding to cordial and reasonable requests to
adjust these do allow it to address, albeit extremely clumsily, the
extremely wide spectrum involved here.

As a postscript, it seems like the term "agenda" was a regrettable
choice for this thread given that it carries an implication of
underhanded and dishonest motives. As I am certain that would never be
the intention of my dear colleagues, to avoid any possible
misinterpretations for the remainder of my message I have adopted
alternative terms instead.

  [0] Or, if you may excuse an RFC2119 pun, "MUST"...
  [1] Feel free to dilute to taste with similar terms.


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] 🍥 chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Chris Lamb -2
In reply to this post by Theodore Y. Ts'o
Theodore Ts'o wrote:

> P.S.  I'm going to be adding an override in e2fsprogs for
> package-supports-alternative-init-but-no-init.d-script because it
> has false positives

Regardless of the specifics of this particular package if Lintian
could feasibly not emit this false-positive, would it surely not be
more sensible to get this fixed there instead?

That would not only be a cleaner solution than an override (which you
would likely just have to remove later...) it would be a general
kindness in that it could potentially save countless other developers
undergoing the same manual process as you.

> It most *definitely* is not certain.

Again, this sounds like something trivially addressed in Lintian
itself, or perhaps even by not reading too much into this apparently
entirely-adjunct advisory classification that is, after all, not
central to Lintian's operation.


Best wishes,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] 🍥 chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

Re: Is it the job of Lintian to push an agenda?

Russ Allbery-2
In reply to this post by Sam Hartman-3
Sam Hartman <[hidden email]> writes:
>>>>>> "Ansgar" == Ansgar Burchardt <[hidden email]> writes:

>     Ansgar> If we have no consensus that doing something is the right
>     Ansgar> thing, then lintian should probably not start raising a
>     Ansgar> warning about it and one should keep in mind that Policy
>     Ansgar> might not reflect consensus when referring to it.

> When the policy decision was made, I think we did have consensus.

> So, no, that's our current policy at least until something changes it.

For the record, this is exactly the way that I view it as well.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: systemd services that are not equivalent to LSB init scripts

Simon McVittie-7
In reply to this post by Theodore Y. Ts'o
On Sun, 14 Jul 2019 at 09:21:37 -0400, Theodore Ts'o wrote:
> P.S.  I'm going to be adding an override in e2fsprogs for
> package-supports-alternative-init-but-no-init.d-script because it
> has false positive, regardless of its claim:
>
> N:    Severity: important, Certainty: certain
>
> It most *definitely* is not certain.  We went through quite a bit of
> trouble providing alternative functionality via cron, and not via
> (only) systemd timers.

Every LSB init script is equivalent to a systemd service that is
"required" or "wanted" by one of the targets that are reached during boot,
but the converse is not true. Not every systemd service is "required"
or "wanted" by those targets: some systemd services start on-demand,
which is not a concept that exists within the narrower scope of LSB
init scripts. Some of the triggering events have equivalents (at least
approximately) in a broader non-systemd ecosystem that includes things
like cron; others do not.

Putting this one first because I think it's the least ambiguous:
Some systemd system services are meant to be started on-demand via
D-Bus activation (/usr/share/dbus-1/system-services/*.service with
SystemdService= pointing to a systemd.service(5)). If the D-Bus
service has a suitable Exec= line, then dbus-daemon can launch the
daemon via traditional D-Bus activation (dbus-daemon-launch-helper)
on non-systemd-booted systems; but on a systemd system it's best if it
configures SystemdService= to delegate that job to systemd, because unlike
systemd, dbus-daemon is not really designed to be a service manager,
and is certainly not a fully-featured service manager. udisksd in the
udisks2 package is one of the canonical examples of this pattern. This
is probably not allowed by a strict reading of Policy, but in the case
where traditional activation already works (which in practice it usually
does) there's clearly no actual functional bug for non-systemd users -
the service is working as well as it ever did - so it should be allowed.

Some systemd system services are meant to be triggered by systemd timers
(systemd.timer(5)), which trigger execution of a systemd service when
the timer "goes off", and can have an analogous (ana)cron job used on
non-systemd-booted systems. It sounds as though your use-case in e2fsprogs
is a good example of this; apt is another. As with D-Bus above, this
doesn't seem to be allowed by a strict reading of Policy. I think the case
where there is an approximately equivalent cron job should certainly be
allowed. If there is no equivalent cron job, I would personally say that's
a bug but probably not RC; it would be in the spirit of previous Technical
Committee decisions on init systems to expect maintainers to apply good
patches, if someone with an interest in non-systemd inits contributes
a cron job that doesn't seem like it will harm future maintenance.

Some systemd system services are meant to start on-demand via socket
events (systemd.socket(5)), and can work via inetd on non-systemd-booted
systems. micro-httpd appears to be an example of this - I'm a bit surprised
there aren't more. Perhaps this indicates limitations in the infrastructure
around inetd services making it hard to implement "use systemd.socket(5)
under systemd or inetd otherwise"?

Some systemd system services are meant to start during suspend/resume by
hooking into targets like suspend.target, and could presumably work via
/etc/pm or /etc/acpi or whatever else non-systemd users use for power
management events on non-systemd-booted systems (I've lost track of what
that would be). tlp-sleep.service in the tlp package is an example, which
appears to hook into elogind via /lib/elogind/system-sleep/49-tlp-sleep,
a mechanism of which I was not previously aware.

Some systemd system services (I don't know of any examples in Debian)
are meant to be triggered by an inotify event (systemd.path(5)), which
could presumably have an equivalent using something like the incron
package if non-systemd users want it badly enough. I don't think the
maintainers of any systemd services that make use of that mechanism
should be expected to invent a whole parallel infrastructure that they
will not, themselves, use, but if non-systemd users build a suitable
mechanism, then it might be reasonable to expect service maintainers
to apply patches that add simple integration "glue" files analogous to
.path units for that other mechanism.

I've deliberately been saying "the non-systemd ecosystem" rather than
"the sysvinit ecosystem" because the latter would be very misleading -
sysvinit itself is really very simple, and its only contribution to any
of this is to run /etc/init.d/rc at runlevel changes. For full coverage
of equivalents of the units I described above it would be at least the
sysvinit/sysv-rc/cron/anacron/dbus-daemon-launch-helper/inetd/elogind/incron
ecosystem, and I'm sure I've missed some.

systemd system services can also be linked to an arbitrary non-boot
unit by declaring that they are WantedBy the other unit, and I don't think
there can be a general solution for that in the non-systemd ecosystem.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: systemd services that are not equivalent to LSB init scripts

Vincent Bernat-3
 ❦ 14 juillet 2019 19:23 +01, Simon McVittie <[hidden email]>:

> Some systemd system services are meant to start on-demand via socket
> events (systemd.socket(5)), and can work via inetd on non-systemd-booted
> systems. micro-httpd appears to be an example of this - I'm a bit surprised
> there aren't more. Perhaps this indicates limitations in the infrastructure
> around inetd services making it hard to implement "use systemd.socket(5)
> under systemd or inetd otherwise"?

inetd uses stdin/stdout to communicate with the daemon and have to
launch one instance for each client connecting. systemd.socket pass a
regular listening socket on first connection to the daemon and the
daemon can then serve multiple clients. It is simple to convert an
existing daemon to systemd.socket and it doesn't come with a performance
impact. It can even simplify some aspects of an always-running daemon,
like reloading without impacting the traffic.
--
Familiarity breeds contempt -- and children.
                -- Mark Twain

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: systemd services that are not equivalent to LSB init scripts

Russ Allbery-2
Vincent Bernat <[hidden email]> writes:

> inetd uses stdin/stdout to communicate with the daemon and have to
> launch one instance for each client connecting. systemd.socket pass a
> regular listening socket on first connection to the daemon and the
> daemon can then serve multiple clients.

I believe the wait option for at least xinetd behaves in roughly the same
way, although it's normally only used for UDP services.

There seems to be a clear infrastructure gap for the non-systemd world
here that's crying out for some inetd-style program that implements the
equivalent of systemd socket activation and socket passing using the same
protocol, so that upstreams can not care whether the software is started
by systemd or by that inetd, and provides an easy-to-configure way for
Debian packages to indicate this should be used if systemd isn't in play.
It doesn't seem like it would be too difficult to implement such a thing,
but I don't think it already exists.

I believe the convention in the runit/daemontools world is to decide this
is not an important problem to solve and lots of small running daemons is
not something that needs to be avoided, and to use tcpserver or some
equivalent that behaves like inetd for a single service.  Even here,
though, I'm not sure if any of those implementations use the same socket
passing protocol as systemd, and I'm not sure if they're yet trivial to
configure as part of Debian packaging.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

12