Dear sysvinit maintainers,

you can find at
<https://salsa.debian.org/debian/sysvinit/-/merge_requests/16> a patch
that removes the Essential bit from sysvinit-utils (a stepping stone
towards fixing <https://bugs.debian.org/826215> and
<https://bugs.debian.org/954306>).

The Essential bit can be removed because, after years of work, no
package make use of `pidof` in their maintscripts. (Except 5 low-popcon
packages for which patches and bug reports has already been submitted.)

Once sysvinit-utils is no longer Essential, the plan towards making it a
normal (i.e., Priority: optional) package would roughly be:

1. Ensure that all package that use `pidof` at runtime (not as part of
their initscripts) gain a dependency on `procps` (even though it does
not ship `pidof` yet). The preparatory work is completed and a MBF will
be announced in the next few days on debian-devel@ (~90 packages are
affected).

2. Once the bulk of the MBF bugs will be dealt with, patched versions of
`sysvinit-utils` (losing `pidof`) and `procps` (gaining `pidof`) should
be uploaded during the same dinstall, to unsure no disruption to Debian
users. You can find draft version of these patches at
<https://salsa.debian.org/gioele/sysvinit/-/compare/non-essential...pidof-remove?from_project_id=109534>
and <https://salsa.debian.org/gioele/procps/-/compare/master...pidof-enable>

3. In Debian 15 Duke the Priority of `sysvinit-utils` will be lowered to
`optional` and systems without `sysvinit-core` will drop it.

Regards,

Hi, any feedback on this plan?

I'd like to move this forward while the analysis (no pidof is used in
maintscripts and a clear list of users at runtime) is still valid.

If you (both sysvinit and procps maintainers) agree on the the plan but
would prefer having to spend extra time working on this, then I
volunteer to NMU sysvinit first, carry out the MBF (including
kick-starting the discussion on d-devel@), and, later, carry out the
simultaneous NMUs of the modified sysvinit and props packages.

This transition can easily be wrapped up before forky is frozen, as long
as it is started soon.

Regards,

Gioele,

Thanks for this and your patience in waiting for a reply.

There have been some discussions and there is uncertainty that your proposed
migration covers all the necessary angles.

Quoting from your original email:

I have been reading the Policy in the hope of finding an escape from the bind we
are in. Policy says:-

  Packages are not required to declare any dependencies they have on other
  packages which are marked Essential (see below), and should not do so unless
  they depend on a particular version of that package. [4]

and [4] adds

  Essential is needed in part to avoid unresolvable dependency loops on
  upgrade. If packages add unnecessary dependencies on packages in this set, the
  chances that there will be an unresolvable dependency loop caused by forcing
  these Essential packages to be configured first before they need to be is
  greatly increased. It also increases the chances that frontends will be unable
  to calculate an upgrade path, even if one exists.

  Also, functionality is rarely ever removed from the Essential set, but
  packages have been removed from the Essential set when the functionality moved
  to a different package. So depending on these packages just in case they stop
  being essential does way more harm than good.

So, currently no callers of pidof or init-d-script should declare an unversioned
Depends: sysvinit-utils.

But, by removing the Essential bit, all users of pidof or init-d-script (not
just maintscript users) will immediately become RC buggy by failing to comply
with the Policy requirement that

  Every package must specify the dependency information about other packages
  that are required for the first to work correctly.

So which of these Policy directives do we break?

The consensus from the discussions we have had so far is that it would be best
to add Depends: sysvinit-utils where required *before* removing its Essential
bit to avoid any time where the necessary dependencies are not declared.

There is also an issue that the commandline options of procps' pidof are not
identical. Are you sure there are no runtime users of pidof that rely on the
current semantics?

Do you see a better way through?

With best wishes

Mark

Hi, thanks for taking the time to evaluate my proposal and draft such a
detailed response!

Before addressing your comments I would like to remind you that removing
Essential:yes is only the first step of the process. I'll focus on it in
this reply, but the whole process described in my original email is what
should be agreed upon.

Right. But keep in mind that these are two different use cases, to be
discussed and treated differently.

Right.
overlooking something. Please poke holes in my reasoning.

There are three categories of pidof-using packages:

pidof0. use pidof in their maintscripts;
pidof1. use pidof in their init.d scripts;
pidof2. use pidof at runtime.

(Obviously some packages belong to more than one category.)

Category pidof0 is now empty (OK, there are at the moment 4 low-popcon
packages left. They will be NMUed before Essential is removed), so we
ignore it for the rest of this discussion.

Then there are two init systems:

init1. sysvinit
init2. systemd

(For the sake of the following analysis, all other init systems can be
grouped into init1 with minor or no changes.)

So in total we have to understand what happens in four scenarios:

A = pidof1 + init1
B = pidof1 + init2
C = pidof2 + init1
D = pidof2 + init2

# Scenario A (pidof in init.d-script, sysvinit)

All sysvinit systems have sysvinit-core, which ships /sbin/init.
sysvinit-core hard-depends on sysvinit-utils (currently for min-version
reasons, but that constraint can be removed and the dependency left in
place).

This means that whenever an init.d-script will actually be run, it will
surely find sysvinit-utils  in place (and thus also pidof).

Removing the Essential bit will have no effect in this scenario.

# Scenario B (pidof in init.d-script, systemd)

sysvinit-utils may or may not be installed, but no init.d script will
actually be run at runtime. (I checked: none of the pidof-using
init.d-scripts are used inside systemd service units in Exec*= lines. I
checked manually, so there may be mistakes, but we are talking about a
handful of packages at worst.)

Removing the Essential bit will have no effect in this scenario.

# Scenario C (pidof at runtime, sysvinit)

Like scenario A: sysvinit users always have sysvinit-utils installed, so
the programs will always have pidof available at runtime.

Removing the Essential bit will have no effect in this scenario.

# Scenario D (pidof at runtime, systemd)

This is the one scenario that needs careful handling.

Theoretically and strictly speaking, without an explicit dependency on
sysvinit-utils, packages that use pidof at runtime will break in some
way. And be RC-buggy because of a missing dependency. This is why a MBF
is needed.

However, a future sysvinit-utils without Essential: yes will still have
Priority: required. This means that, in practice, debian-installer
(through debootstrap) will still install sysvinit-utils an all systems
because of its Priority, even if it is not Essential. It will also be
kept during updates.

What about removals? Policy states:
So if a user actively _removes_ sysvinit-utils and some package on their
system break, then they cannot complain. Same for systems created using
tools like mmdebstrap by forcing a minimal selection of packages. (But I
don't really like this attitude, so please keep reading and we will deal
with this.)

So, in this scenario removing Essential may cause some breakage. But, in
practice, no normal user will see it. (I can tell you as use of
mmdebstrap+custom package sets, that there similar breakages are
constantly present.) It will also make the package theoretically
RC-buggy, but once the MBF and the transition to procps is over, then
everything will be as good as before (actually better because there will
be an explicit documentation of the use of pidof via Depends:).

That is the aim of the MBF proposed as step 1 of the follow-up plan
described in the first mail of this bug report: to tell all affected
packages to add a dependency to the package with pidof. These bug
reports can later be turned into RC-severity bugs for the last
stragglers. However, going forward it makes little sense to use pidof
from sysvinit-utils, Debian should rather use the one from procps. So,
to avoid having to later change those dependencies from sysvinit-utils
to procps, the MBF should directly suggest switching to procps.

The cool thing is that, in practice, we don't need the MBF to be over to
remove Essential from sysvinit-utils. sysvinit-utils is Priority:
required, procps is Priority: important, so both packages are already
installed on all normal systems. Adding these explicit dependencies is
only needed, in practice, to accommodate users of custom installation
methods like mmdebstrap.

I would not worry about this. Upstreams that call pidof at runtime do
not know which implementation is going to be executed. And given that no
other big distro ships pidof from sysvinit we can be pretty sure that
all upstream usages of pidof are compatible with procps. Same for
upstream-provided init.d-scripts.

Regards,

Hello Mark,

Thanks for providing feedback on this topic! Even though I promised
myself to stay out of this discussion, I can't help but add my 5c...
Hopefully you find something informational, helpful and/or maybe
interesting from a historical perspective, otherwise please feel free to
ignore.

In my opinion (and also apparently the opinion of sysvinit maintainers
in the past, more on this later) is that sysvinit should pull in the
parts that is the expected execution environment for init scripts
(instead of duplicating this in every package that ships an init
script - which I agree is probably better maintained by
application maintainers themselves if possible).

The solution is that src:sysvinit in the same version that drops the
essential bit from sysvinit-utils, also adds a dependency on the package
that provides pidof implementation. No policy violation, no bugs
introduced.

This actually used to be the situation in the past, that sysvinit
depended on sysvinit-utils.... so this was not a problem until
someone decided to make this a problem by fixing the policy violation
by dropping the dependency instead of dropping the essential bit as
requested. Feel free to do your own bug tracker and git[1] history
archeology if you want more details.

Any such code is already non-portable to any other distribution (which
uses the procps implementation of pidof), so I would consider that a bug
unless it's in debian-specific code (i.e. maint scripts, which have all
been investigated).

Yes, the solution is that sysvinit re-adds the sysvinit-utils dependency, as
already mentioned as already mentioned above.


I would also like to add that any init script that directly invokes
pidof is likely buggy and should instead use LSB pidofproc (or even some
more high level function, possibly even a policy-mandated helper).
Probably a good idea to expose those bugs and get them fixed at some
point (or how long should we keep working around buggy init scripts
instead of fixing them?).

Another point here is that the work Gioele mentioned has happened to get
rid of pidof usage has been almost exclusively been "replace pidof usage
with policy mandated helpers". Policy is not supposed to be something to
hide behind, but something to help guide us. When policy is buggy or
problematic, we fix policy (which is still in need of alot of love as
always). We could have proceeded by just filing RC bugs and gotten rid
of all blockers from the archive, but we proceeded to fix bugs instead.
I'm hoping we can work to fix bugs and make progress instead of discuss
what our personal preferred interpretation of policy is.

FWIW policy also used to document implementation details about sysvinit
that would make the entire existance of startpar and insserv be RC bugs
until yours truely got those parts removed from policy (because fixing
policy was the correct way forward instead of arguing about policy
violations even though fixing policy in this single case was a
multi-year effort to get the changes actually merged... unchanged).

Over the past few releases a number of people have been involved with
getting rid of essential bit from several packages and also getting
priority downgraded on even more packages, to avoid them being part
of the minimal debootstrap set. This work has been hugely sucessful
with minimal impact to the overall usage of debian. If we can't make
progress on low-hanging fruit like sysvinit-utils until all init scripts
has been removed from the archive, then so be it...

Regards,
Andreas Henriksson


[1]: 8ce88afb25862849f402a1d46cf081aa65ac7438

(And not just init-d-script which benefits a minority of packages but
init-functions and vars.sh etc. which would affect a large number.)

I do like the idea of avoiding extra friction for individual packages to
be able to hold an initscript. At worst I think we should require
dh_installinit to add to ${misc:Depends}, which would avoid source
packages needing to tbe changed, but much better is if the dependency
does not even need to be expressed in the binary package at all, as I
think you are implying.

My concern is whether we have identified all the use cases
comprehensively and how much it matters for any that would not have this
implied dependency satisfied.

Considering the use cases:

 1) sysv-rc - the obvious one - easy, and already satisfied by a
    versioned Depends, as it happens!

 2) openrc, runit-init, etc., where fallback to initscripts is key to
    being comprehensive - presumably straightforward.

 3) initless containers and similar.

The last one is the interesting one. Are there any use cases for
initscripts being launched in isolation, by invoke-rc.d or similar? I
have seen this happen benefically in autopkgtests (not sure which
backend etc. - the same test used systemd in salsa and debci) for
example. I am not saying this is a big deal, that the use cases are
numerous or that they wouldn't already be satisfied indirectly[1], but I
think this deserves a little examination before proceeding, not least
because it might overlap with whatever the use cases are that are going
to benefit from this slightly reduced Essential set!

Thanks,

Andrew

[1] Or perhaps such use cases are potentially better satisfied by
src:systemctl.

Hi Andrew,

I believe my analysis <https://bugs.debian.org/1131136#18>, in
particular of Scenario A, addresses all your points (except one, see
below). Feel free to point out parts that you find wrong or problematic.
environment in which sysvinit-core is installed, and it brings in
everything that is needed to run init.d-scripts, including
sysvinit-utils (that is Priority: required anyway).

Counterargument: Should all packages that ship an openrc file also
Depend on openrc?

My analysis covers autopkgtests and the MBF will include 11 packages
whose autopkgtest control file will have to be fixed. (I haven't spoken
much about the details of the MBF because they do not matter until there
is agreement about the overall plan.)

What my analysis do not cover are cases of programs a) running
init.d-scripts b) at runtime (outside build-time tests and autopkgtests)
c) in a system that uses systemd. I do not know if such programs exist.
If they do, they probably already have measures in place to be able to
run in distros that do not support sysvinit at all. And for the couple
of programs that don't do, they will be flagged by their users and their
dependencies will be patched in unstable. Are any such programs known?

Regards,

Gioele,

I think we might have a confusion in terminology. I apologise in advance if I am
already stating something you know.

By init-d-script I believe Andrew and I mean the init-d-script(5) library
installed at /usr/lib/init/init-d-script by sysvinit-utils that allows
declarative LSB initscripts. Any package that uses init-d-script(5) requires
sysvinit-utils be installed, as identified by Michael in #826215.

It seems as if packages using init-d-script(5) need to gain a dependency on
sysvinit-utils before the Essential bit is removed.

It is certainly true that when sysvinit-core in installed, the versioned
sysvinit-utils dependency should prevent breakage, although it falls short of
what is required by Policy.

However, there is a usage case for LSB initscripts in initless containers when
sysvinit-core is not installed and therefore neither sysvinit-utils. In such
containers I routinely run 'service <name> start|stop...'. Maybe that is just my
habit; I don't know how common such practices are.

Apologies again if I have misinterpreted what you wrote.

Best wishes

Mark

In any such cases the image builder simply has to pull in what they
require for their custom use cases, like they already do for anything
else they want to include in such images. This is really not a reason
to make something "essential" and thus mandatory for _every_ single
installation/image/etc regardless of the use case, otherwise it would
equally apply to any other of the ~60k binary packages that anybody
might want to use in a custom local setup. The change can be
communicated in a NEWS entry and in the release notes.

Hi Mark,

thanks for the clarification. I was indeed not thinking of
init-d-script(5). Now I have integrated it in my analysis.

1. Custom installations (like init-less container images). As Luca said,
custom setups always have to do additional steps in order to get the
level of customization they like. Adding sysvinit-tools will be just one
of other similar steps (and will be documented in NEWS).

2. Initscripts run on systems where init=sysvinit. These initscripts
will find pidof and init-d-script where they expect it because
sysvinit-utils is pulled in by sysvinit-core. No extra dependencies needed.

3. Initscripts run on systems where init=systemd. These initscripts will
run only if called at runtime by programs (or systemd service units)
shipped by a package. Do these packages exist? Yes, I extended my
semi-manual analysis to extra 1200 candidate packages and, in fact,
there is a couple of packages that ship programs that call initscripts
at runtime. In the future (not soon once Essential=yes will be gone, but
only once Priority will be set to optional), these packages will fail at
runtime because of the lack of init-d-script. At that point they will
need to hard-depend on sysvinit-utils.

To fix 3, maybe I could start a small MBF for "this package needs
sysvinit-utils as Depends: because it uses files from it (except pidof)
at runtime/test-time" before removing Essential:yes from sysvinit-utils?

But back to the initial intent of the bug report: is there consensus,
that, with these minor issues fixed:

a) the Essential bit can be removed, and
b) pidof can be removed from sysvinit-utils and procps can start
shipping it (once the pidof-related MBF is mostly completed)?

?

Regards,

Hi Gioele and others,

Thank you for your effort to make sure all use cases are considered!

Yes, as I continued, IMHO it is preferrable to have an indirect way of
expressing this environment-specific dependency rather than doing the
above.

At present, I don't believe any packages ship openrc integration other
than fallback initscripts because they don't have an overriding
directory where they can use the openrc interpreter. (I expect that
openrc users will want to add such a thing in due course so they can get
the full benefit of openrc.) So packages won't need to change but openrc
will need to gain a dependency on sysvinit-utils, obviously.

I don't know of anything specific and agree any cases in the archive can
be handled as found.

Personally I was mostly concerned about the impact of helper scripts not
being present and making sure it remains low friction for package
maintainers to (helpfully) carry initscripts with their services. I am
convinced that this transition will be OK from this perspective,
although I don't write for anyone else.

Did anyone identify the different command line options of procps's pidof
for the benefit of this thread? I have a feeling this command is not
infrequently used in third party software, but of course the affected
options might be niche.

Thanks,

Andrew

Having the dependency in a few more central packages (instead of in
every leaf package) would make it easier to switch to a different
package potentially providing pidof in the future,
which I personally think would be nice (if that ever happens).

I don't want to repeat the "lets add lsb-base dependency to half of all
the packages in the archive and then remove it again" dance.

IIRC sysvinit pidof has -z which is not present in procps pidof.

This discussion would however probably fit better on a bug report about
which implementation to use, not on the essential-or-not bug report.

Regards,
Andreas Henriksson

Side note:

openrc 0.64 will support /etc/rc/ as location for "native" openrc
scripts. There are few packages shipping a "native" openrc script, and
they use the sysvinit ones. As long as the use those they will need to
deal with all the sysvinit stuff (insserv, sysvinit-utils, etc.).

However, I hope to move at least a small essential set to native openrc
ones. Ideally, openrc is decoupled from sysvinit one day, but I don't
see that happening for forky.

best,

werdahias

Hi Andreas,
but to /usr/lib/{init/init-d-script,lsb/init-functions}.

Andrew's reasoning is that (Andrew, please correct me if I'm wrong),
once sysvinit-utils is no longer Essential, every package that ships an
init-script should Depends: on sysvinit-utils because init-scripts
should be able to run in any environment (also where init=systemd) as
normal programs. Given that many init-scripts require
/usr/lib/init/init-d-script, the packages that ships them should ensure
that that file is available ⇒ Depends: sysvinit-utils.

My position is: not all packages that ship an init-script should depend
on sysvinit-utils. Why? Because init-scripts are not run-time components
of upstream programs (except a handful of cases that will, in fact
require Depends: sysvinit-utils). If a user (not a program) wants to run
an init-script, they must take care of making available everything that
the init-script requires. That means installing at least sysvinit-core
or -utils.

BTW, sysvinit-utils will still be "Prio: required" for at least a
release, so no breakage will happen in standard installations.

A final analogy: adding sysvinit-utils to the Depends: of a package just
because it ships an initscript seems to me as wrong as making a package
hard-depend on `foo` just because `foo` is needed to run one of the
examples in the documentation.

Regards,

Hi Gioele,

I know that you likely already checked this, but just to be on the safe
side; You already checked or know for fact that all daemon's
postinst script in Sid use invoke-rc.d's "--skip-systemd-native"
option, that's correct?
I had a very quick look at dh_installinit code and it seems
"--skip-systemd-native" is hardcoded, but it's injected with
some condition (is it the compat level?)

Best,
Lorenzo

Gioele,

Thanks
init-d-script(5). This could be addressed by teaching dh_installinit to add
Depends: sysvinit-utils to ${misc:Depends} or similar. But this needs to be done
before Essential is dropped.

It isn't the user's responsibility to work out the dependencies of a package, it
is declared by the package itself. Policy is clear about that. Obviously Policy
can be changed and if you want to do that, please build the necessary consensus

Mark

In fact I did not check that. Thanks for the suggestion.

A quick analysis reveals that most maintscripts use
--skip-systemd-native except in ~120 cases (plus ~160 cases of 
invoke-rc.d without --skip-systemd-native generated by dh_installinit in
compat <= 10). Pretty much all these cases come from manually written
maintscripts, whose correctness and robustness are questionable.

* config: 2
* preinst: 6 (+ 3 via dh_installinit)
* postinst: 70 (+ 78 via dh_installinit)
* prerm: 37 (+75 via dh_installinit)
* postrm: 18 (+ 4 via dh_installinit)

These are worst-case/upper-limit figures. Many of these occurrences are
surrounded by ad-hoc logic that tests whether systemd is running before
launching invoke-rc.d.

dh_installinit should be fixed to unconditionally use
`--skip-systemd-native` (see <https://bugs.debian.org/1134840>).

Regards,

It seems to me that that this is the main friction point of this branch
of the discussion: should common initscripts (common as in "used only to
start/stop daemons and not executed at runtime by an upstream program")
be seen as normal programs that users can run on their own even on
non-sysvinit systems? If yes, all packages that ship an initscript
should Depends: or Recommends: all the necessary packages (including
sysvinit-tools). If not, then users will be responsible for manually
installing the required packages (like they are for scripts shipped by
many packages in examples/ directories).

We have expressed our opinions. But they remain opinions.

To unblock this specific issue and make it possible to discuss the rest
of the plan, shall we prepare a case and submit it to the tech-ctte?

In the meantime, can we reach agreement on moving pidof to procps? That
will enable beginning the pidof-related MBF.

Regards,

Gioele,

Thanks
provide a way through.

The arch independent files currently in sysvinit-utils, namely

 /usr/lib/init/init-d-script
 /usr/lib/init/vars.sh
 /usr/lib/lsb/init-functions
 /usr/lib/lsb/init-functions.d/00-verbose
 /usr/share/man/man5/init-d-script.5.gz

fit neatly within the Description of init-system-helpers.

Description: helper tools for all init systems
 This package contains helper tools that are necessary for switching between
 the various init systems that Debian contains (e. g. sysvinit or
 systemd). An example is deb-systemd-helper, a script that enables systemd unit
 files without depending on a running systemd.
 .
 It also includes the "service", "invoke-rc.d", and "update-rc.d" scripts which
 provide an abstraction for enabling, disabling, starting, and stopping
 services for all supported Debian init systems as specified by the policy.
 .
 While this package is maintained by pkg-systemd-maintainers, it is NOT
 specific to systemd at all. Maintainers of other init systems are welcome to
 include their helpers in this package.

which is also Essential.

If we were to move these files to init-system-helpers, we think it would address
all our concerns about their assumed availability, even in initless chroots and
the like.

We would want to ensure that any modifications required to these files would be
easy to enact and would welcome assurance from the Maintainers of
init-system-helpers that adding another Uploader would be welcomed.

If agreed and once the move was completed, we think this would enable the dropping of
Essential and subsequent change of pidof provider.

What do you think?

Best wishes

Mark

in; it doesn't make sense for other init systems to do so. Having init
systems with init script support depend on sysvinit-utils solves 99% of
cases. The only cases that aren't covered by that are cases where a
package ships an init script or helper script that sources one of these
*and* expects to call that script on a system that doesn't have an
init-script-based init system installed (or may not have any init at
all). For instance, this would apply to a package that ships
/etc/init.d/foo *and* has some non-init script (e.g. a cron job) that
invokes the init script.

To the extent that packages do that (which they shouldn't), it seems
reasonable to say "if your package does that, you need an explicit
dependency on sysvinit-utils yourself, because it might be invoked on a
system without an init system".

That would have the ideal outcome:
- Systems containing only packages that *don't* invoke such scripts
  outside the context of an init system will not need these files.
- Systems containing packages that *do* invoke such scripts outside the
  context of an init system will pull in these files.
- Most importantly, nothing Essential or transitively essential pulls in
  these files, which also means we won't get *new* undocumented
  dependencies on them.