Bug#827376: init-system-helpers: invoke-rc.d unconditionally uses /sbin/runlevel without depending on a package providing it

Andreas Beckmann

unread,

Jun 15, 2016, 9:10:03 AM6/15/16

to

Package: init-system-helpers
Version: 1.34
Severity: important

Hi,

I just noticed this in a piuparts log (#827374):

/usr/sbin/invoke-rc.d: 1: /usr/sbin/invoke-rc.d: /sbin/runlevel: not found
invoke-rc.d: could not determine current runlevel
invoke-rc.d: policy-rc.d denied execution of reload.

/sbin/runlevel is provided by several packages:

https://packages.debian.org/search?mode=path&suite=sid&section=all&arch=any&searchon=contents&keywords=sbin%2Frunlevel

so I'm not sure what the correct Depends would be ...

Andreas

Michael Biebl

unread,

Jun 15, 2016, 9:20:03 AM6/15/16

to

Hi Andreas

Am 15.06.2016 um 15:02 schrieb Andreas Beckmann:
> I just noticed this in a piuparts log (#827374):
>
> /usr/sbin/invoke-rc.d: 1: /usr/sbin/invoke-rc.d: /sbin/runlevel: not found
> invoke-rc.d: could not determine current runlevel
> invoke-rc.d: policy-rc.d denied execution of reload.
>
> /sbin/runlevel is provided by several packages:
>
> https://packages.debian.org/search?mode=path&suite=sid&section=all&arch=any&searchon=contents&keywords=sbin%2Frunlevel
>
> so I'm not sure what the correct Depends would be ...

We recently changed "init" to no longer be essential. This means
/sbin/runlevel is no longer guaranteed to be around.
In case of invoke-rc.d it's probably best to have a sensible fallback if
runlevel can't be found.

That said, we probably have more places where those binaries provided by
systemd-sysv (halt, telinit, runlevel etc) are used. So there might be
some more fallout from that change.

Any idea how we can users of
https://packages.debian.org/sid/alpha/systemd-sysv/filelist
?

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

signature.asc

Michael Biebl

unread,

Jun 15, 2016, 9:30:03 AM6/15/16

to

Am 15.06.2016 um 15:15 schrieb Michael Biebl:

> Any idea how we can users of
> https://packages.debian.org/sid/alpha/systemd-sysv/filelist

... how we can *identify* users of ...

signature.asc

Andreas Beckmann

unread,

Jun 15, 2016, 11:00:03 AM6/15/16

to

On 2016-06-15 15:15, Michael Biebl wrote:
> We recently changed "init" to no longer be essential. This means
> /sbin/runlevel is no longer guaranteed to be around.
> In case of invoke-rc.d it's probably best to have a sensible fallback if
> runlevel can't be found.
>
> That said, we probably have more places where those binaries provided by
> systemd-sysv (halt, telinit, runlevel etc) are used. So there might be
> some more fallout from that change.
>

> Any idea how we can *identify* users of
> https://packages.debian.org/sid/alpha/systemd-sysv/filelist

In this list of binaries probably only runlevel is really interesting
and maybe telinit. I don't expect the other commands to be used from
maintainer scripts (or inside chroots at all).

/sbin/halt
/sbin/init
/sbin/poweroff
/sbin/reboot
/sbin/runlevel
/sbin/shutdown
/sbin/telinit

We could use piuparts :-)

dpkg-divert runlevel and telinit (and maybe everything else, too) and
replace them all with a script that, if called, checks if the divertee
exists and execs it. Otherwise throw a big fat warning in a way that
cannot be ignored by the package (writing to a piuparts-internal logfile
inside the chroot) and make the piuparts test fail afterwards.
Will create false positives on scripts doing
if [ -x /sbin/$cmd ]; then
$cmd
else
do_something --without $cmd
fi

That should be manageable with two new custom scripts, thereafter rerun
sid, experimental, jessie2stretch ...
But invoke-rc.d needs to be fixed first, otherwise (nearly) everything
will fail. And fixing invoke-rc.d might produce false positives
globally, so nothing gained.

Or maybe runlevel should just find a new home and stay essential. That's
something that probably should be available (and independent from the
actual init system being used).

The codesearch results for "telinit" seem manageable for manual checking
https://codesearch.debian.net/results/telinit
while "runlevel" is just a common word, and seldom a command.

Andreas

Martin Pitt

unread,

Jun 28, 2016, 5:00:03 AM6/28/16

to

Control: tag -1 pending

Hello,

Andreas Beckmann [2016-06-15 15:02 +0200]:

> I just noticed this in a piuparts log (#827374):
>
> /usr/sbin/invoke-rc.d: 1: /usr/sbin/invoke-rc.d: /sbin/runlevel: not found

This is mostly cosmetical, I fixed this in

http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=58d547

Thanks for the report!

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt

unread,

Jun 28, 2016, 5:00:05 AM6/28/16

to

Hello Andreas,

Andreas Beckmann [2016-06-15 16:49 +0200]:

> But invoke-rc.d needs to be fixed first, otherwise (nearly) everything
> will fail. And fixing invoke-rc.d might produce false positives
> globally, so nothing gained.

invoke-rc.d is actually behaving correctly already, it just shows that
confusing error message (which is now fixed in git, see my other
reply).

> Or maybe runlevel should just find a new home and stay essential. That's
> something that probably should be available (and independent from the
> actual init system being used).

Eek, no. The "runlevel" concept only exists in SysV init. upstart and
systemd try to emulate it to some degree, but only approximately as
they are built on completely different concepts. I actually worked on
making invoke-rc.d not require the concept of runlevel at all under
systemd (I believe 1.35 is good in that regard now).