Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Daniel Kahn Gillmor]

On Fri 2017-06-02 02:53:47 +0200, Michael Biebl wrote:
> Seems like you want a Breaks/Replaces: runit-init in runit to ensure the
> package is properly upgraded for users who have already runit-init
> installed.

good call, thanks for the reminder.  I'll do that in 2.1.2-9.2, which
i'll upload shortly and then send an unblock.

 --dkg


signature.asc
Description: PGP signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Michael Biebl]

On Wed, 31 May 2017 13:26:36 -0400 Daniel Kahn Gillmor 
wrote:

> I apologize for the oversight, and want to know if it'd be ok for me to
> upload 2.1.2-9.2 using the attached debdiff.  I've pushed a queue of
> these changes into the "unstable" branch at
> https://anonscm.debian.org/git/collab-maint/runit.git already if you'd
> prefer to review them there.

Seems like you want a Breaks/Replaces: runit-init in runit to ensure the
package is properly upgraded for users who have already runit-init
installed.

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



signature.asc
Description: OpenPGP digital signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Daniel Kahn Gillmor]

Hi all--

On Tue 2017-05-30 13:07:01 -0400, Daniel Kahn Gillmor wrote:
> I've now done this NMU, and filed #863732 to unblock the upload.
>
> I've pushed the changes in a git branch to
> https://anonscm.debian.org/git/collab-maint/runit.git, which is forked
> from of https://anonscm.debian.org/git/users/kaction-guest/runit.git and
> should probably be re-merged at some point.
>
> fwiw, the practice of keeping just the debian/ directory in git seems
> odd to me and makes it more difficult for me to contribute to the
> NMU-maintenance of the package.  if i was going to do more work on the
> package, i'd certainly prefer it to be converted to a standard
> git-buildpackage-style "ladder" repo.

I regret to say that i think i did this upload suboptimally.  by just
dropping the runit-init package, we've left debian users who want runit
as pid 1 with no options other than to rebuild the package, because
nothing is shipping /sbin/runit or /sbin/runit-init.

in jessie, /sbin/runit and /sbin/runit-init are both shipped in the
runit package.

What i should have done is to move /sbin/runit and /sbin/runit-init into
the runit package itself, rather than drop them entirely.

I've made this change and would like to propose a 2.1.2-9.2 upload, with
attached debdiff.  I've tested this with a guest system which now does
load runit as PID 1 when booted with a kernel argument of
"init=/sbin/runit-init".

I apologize for the oversight, and want to know if it'd be ok for me to
upload 2.1.2-9.2 using the attached debdiff.  I've pushed a queue of
these changes into the "unstable" branch at
https://anonscm.debian.org/git/collab-maint/runit.git already if you'd
prefer to review them there.

Regards,

   --dkg

diff -Nru runit-2.1.2/debian/changelog runit-2.1.2/debian/changelog
--- runit-2.1.2/debian/changelog	2017-05-30 11:46:28.0 -0400
+++ runit-2.1.2/debian/changelog	2017-05-31 12:44:38.0 -0400
@@ -1,3 +1,11 @@
+runit (2.1.2-9.2) unstable; urgency=medium
+
+  * non-maintainer upload
+  * re-add /sbin/runit{,-init} to runit package so it remains possible to
+use runit as PID 1
+
+ -- Daniel Kahn Gillmor   Wed, 31 May 2017 12:44:38 -0400
+
 runit (2.1.2-9.1) unstable; urgency=medium
 
   * non-maintainer upload
diff -Nru runit-2.1.2/debian/control runit-2.1.2/debian/control
--- runit-2.1.2/debian/control	2017-05-28 15:07:36.0 -0400
+++ runit-2.1.2/debian/control	2017-05-31 12:44:38.0 -0400
@@ -6,7 +6,6 @@
 Homepage: http://smarden.org/runit/
 Build-Depends: bash-completion,
debhelper (>= 9),
-   dh-exec,
dh-systemd,
dh-runit (>= 1.6),
dh-buildinfo (>= 0.11+nmu1),
diff -Nru runit-2.1.2/debian/rules runit-2.1.2/debian/rules
--- runit-2.1.2/debian/rules	2017-05-28 15:08:57.0 -0400
+++ runit-2.1.2/debian/rules	2017-05-31 12:44:38.0 -0400
@@ -9,9 +9,6 @@
 override_dh_systemd_enable:
 	dh_systemd_enable --name runit
 
-override_dh_installman-arch:
-	dh_installman
-
 override_dh_runit: runscripts/getty
 	dh_runit
 
diff -Nru runit-2.1.2/debian/runit.install runit-2.1.2/debian/runit.install
--- runit-2.1.2/debian/runit.install	2017-05-28 14:51:14.0 -0400
+++ runit-2.1.2/debian/runit.install	2017-05-31 12:44:38.0 -0400
@@ -8,7 +8,9 @@
 runit-*/src/chpst  /usr/bin
 runit-*/src/runsvchdir /usr/sbin
 runit-*/src/utmpset/usr/sbin
+runit-*/src/runit-init /sbin
+runit-*/src/runit  /sbin
 
 runit-*/etc/debian/1   /etc/runit
 runit-*/etc/2  /etc/runit
-runit-*/etc/debian/3   /etc/runit
\ No newline at end of file
+runit-*/etc/debian/3   /etc/runit
diff -Nru runit-2.1.2/debian/runit.manpages runit-2.1.2/debian/runit.manpages
--- runit-2.1.2/debian/runit.manpages	2017-05-28 14:51:14.0 -0400
+++ runit-2.1.2/debian/runit.manpages	2017-05-31 12:40:18.0 -0400
@@ -5,4 +5,6 @@
 runit-*/man/chpst.8
 runit-*/man/runsvchdir.8
 runit-*/man/utmpset.8
+runit-*/man/runit.8
+runit-*/man/runit-init.8
 debian/contrib/update-service.8


signature.asc
Description: PGP signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Daniel Kahn Gillmor]

On Sun 2017-05-28 15:14:24 -0400, Daniel Kahn Gillmor wrote:
> On Sun 2017-05-28 19:54:33 +0200, Ivo De Decker wrote:
>> If this bug can be fixed by removing runit-init, the removal of the other
>> packages isn't necessary, but please note that this would need to happen very
>> soon.
>
> fwiw, i'm willing to provide such an NMU, because i consider runit to be
> a useful package.

I've now done this NMU, and filed #863732 to unblock the upload.

I've pushed the changes in a git branch to
https://anonscm.debian.org/git/collab-maint/runit.git, which is forked
from of https://anonscm.debian.org/git/users/kaction-guest/runit.git and
should probably be re-merged at some point.

fwiw, the practice of keeping just the debian/ directory in git seems
odd to me and makes it more difficult for me to contribute to the
NMU-maintenance of the package.  if i was going to do more work on the
package, i'd certainly prefer it to be converted to a standard
git-buildpackage-style "ladder" repo.

Regards,

 --dkg


signature.asc
Description: PGP signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Chris Lamb]

Hi,

> runit-init: Cannot reboot or shutdown after installing (or removing) the 
> package.

See also:

  https://bugs.debian.org/863539
  https://bugs.debian.org/863541
  https://bugs.debian.org/863542
  https://bugs.debian.org/863543


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Daniel Kahn Gillmor]

Hi there--

On Sun 2017-05-28 19:54:33 +0200, Ivo De Decker wrote:

> On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote:
>> May I suggest only removing runit-init from the runit source package, if
>> the bug can't be fixed in time for the stretch release?
>
> Sure. That just needs someone to upload such an NMU very soon. I suggested
> this already at the end of message #49:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49
>
>> Because runit itself doesn't cause the issue discussed here, is useful
>> on its own, and several packages depend on it.
>
> If this bug can be fixed by removing runit-init, the removal of the other
> packages isn't necessary, but please note that this would need to happen very
> soon.

fwiw, i'm willing to provide such an NMU, because i consider runit to be
a useful package.  However, it'll be done under duress, as i don't think
that the removal of runit-init is strictly necessary.

fwiw, i've run debian systems with runit as PID 1 for years, long before
there was a runit-init package, and without the runit-init package even
today.  So it's certainly possible to achieve the runit-as-pid-1
situation without the package.  But if the only issue with runit-init is
the first reboot when switching initsystems, then i don't think that
should rise to the level of an RC bug.  as written upthread, when you
switch initsystems, some level of pain is to be expected.

removing runit-init from debian just means that people switching init
systems will have *more* pain (because they'll be totally on their own
with the conversion).

anyway, if folks want this NMU in order to keep runit in debian, i'll
provide it, but i don't think it's a great idea.

--dkg


signature.asc
Description: PGP signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Jan Niehusmann]

Hi,

On Sun, May 28, 2017 at 07:54:33PM +0200, Ivo De Decker wrote:
> On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote:
> > May I suggest only removing runit-init from the runit source package, if
> > the bug can't be fixed in time for the stretch release?
> 
> Sure. That just needs someone to upload such an NMU very soon. I suggested
> this already at the end of message #49:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49

But who decides that this is the right way to go? Just removing a
package is not usually something which should be done with an NMU.

Especially as this bug only affects systems switching to runit. There
may be people happily running runit as their init system. Just leaving
them with an unmaintained init system doesn't seem to be a good idea,
either. In fact, that may be less user friendly than this bug. How could
we handle future security issues in that package, for example?

As runit-init is part of current stable, we need to provide some upgrade
path if we want to remove it.

BTW, according to the initial reporter, "The same procedure was required
to return to systemd as PID1." So systemd seems to be broken in the
same way. Therefore, simply replacing runit-init with a transitional
package depending on systemd wouldn't work either.

> If this bug can be fixed by removing runit-init, the removal of the other
> packages isn't necessary, but please note that this would need to happen very
> soon.

Removing runit-init from the init package may be worse than keeping it,
see above.

Of course, removing runit-init, runit and all reverse-dependencies would
be even worse, so it may be a workaround in case the release team
decides that keeping runit-init in its current form is absolutely not
acceptable.

Jan

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Ivo De Decker]

Hi,

On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote:
> May I suggest only removing runit-init from the runit source package, if
> the bug can't be fixed in time for the stretch release?

Sure. That just needs someone to upload such an NMU very soon. I suggested
this already at the end of message #49:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536#49

> Because runit itself doesn't cause the issue discussed here, is useful
> on its own, and several packages depend on it.

If this bug can be fixed by removing runit-init, the removal of the other
packages isn't necessary, but please note that this would need to happen very
soon.

Cheers,

Ivo

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Jan Niehusmann]

May I suggest only removing runit-init from the runit source package, if
the bug can't be fixed in time for the stretch release?

Because runit itself doesn't cause the issue discussed here, is useful
on its own, and several packages depend on it.

Thanks,
Jan

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Jan Niehusmann]

BTW, I really think this doesn't need to be RC.

(Or, at least, should be stretch-ignore, because removing all the
reverse-dependencies would be worse than just shipping with runit-init.)

I agree it's bad to leave a user with a broken system. But in this case,
the user gets an appropriate warning:

root@sid:~# apt install runit-init
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  cgmanager fgetty getty-run libcgmanager0 libnih-dbus1 libnih1 systemd-shim
Suggested packages:
  pm-utils
The following packages will be REMOVED:
  init systemd-sysv
The following NEW packages will be installed:
  cgmanager fgetty getty-run libcgmanager0 libnih-dbus1 libnih1 runit-init 
systemd-shim
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  init systemd-sysv (due to init)
0 upgraded, 8 newly installed, 2 to remove and 0 not upgraded.
Need to get 439 kB of archives.
After this operation, 1,059 kB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] 


If I get such a warning, and answer explicitly by typing "Yes, do as I
say!", I'm not surprised if the system is broken afterwards.

And in this case, the brokenness is easily fixed by hard-rebooting, if I
understand it correctly. Not nice, but not a catastrope.

Jan

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[John Paul Adrian Glaubitz]

On 05/28/2017 12:30 PM, Matthew Hoare wrote:
> Would it be appropriate to provide these commands for temporary use
> after switching init?

This would be hack and not a proper solution which would meet Debian
standards. Really, the only solution here is simply not to replace
the init system from the user side or if you do it, deal with the
fall out yourself.

> I can attempt an NMU but I am relatively unskilled with Debian
> packaging so it may take a while.

We don't have that time anymore. Debian Stretch is going to be released
in less than three weeks. Let's just please remove runit from Stretch.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Matthew Hoare]

I can confirm that this issue also occurs with a fresh (debootstrap)
installation of pure Debian stretch.

I can also confirm that these four commands will reboot into the new
init system without damaging the mounted filesystems:

`echo 1 > /proc/sys/kernel/sysrq`

`echo s > /proc/sysrq-trigger`

`echo u > /proc/sysrq-trigger`

`echo b > /proc/sysrq-trigger`

Would it be appropriate to provide these commands for temporary use
after switching init?

I can attempt an NMU but I am relatively unskilled with Debian
packaging so it may take a while.

-- 
Matthew T. Hoare

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[John Paul Adrian Glaubitz]

On 05/27/2017 11:37 PM, Ivo De Decker wrote:
>> Well, there is also ulibc being shipped with Debian stable. Yet, when
>> someone tries to use it and breaks their system, it's not supported
>> either. So, I don't think this policy can be sweepingly applied to
>> every package.
> 
> There is no package named 'ulibc', so I guess that's a typo. If you meant
> uclibc, that package only ships uclibc-source, so installing that doesn't
> break anything.

Is it really relevant for the discussion whether I made a typo or not?

My point is: There is a package called uclibc-source that people can
install the source from, compile and install to completely hose their
system. Simply because the C library is such a fundamental component
of the system that it cannot be trivially replaced.

To use the popular car analogy: Replacing the installed radio with a
third-party radio will work for most people without issues. However,
replacing the gearbox will probably a lot of more headaches and
requires advanced technical skills and knowledge.

>> I fully agree. However, runit is one of the packages which is not
>> automatically removed.
> 
> No. But it can be manually removed.

Then please let's do this. I already saw it was marked for that which
is good.

>> You really cannot expect a fundamental component like an init system
>> to be easily replace by the end user the same way they can swap their
>> default text editor.
> 
> Well, in that case there shouldn't be a package that tries to swap the init
> system. If there is a package that provides the tools to do so, but lets you
> do it on your own, that's a different story. It will still allow you to break
> your system, but you can do that with lots of tools (certainly with your text
> editor).

Uhm, the package is an alternative init system. Of course, it will try to
replace the init system. What else is it supposed to do?

That's one of the reason I am completely opposed to ship alternative init
systems and the other relevant Linux distributions like Fedora, RHEL,
SLE(D,S) and openSUSE only ship systemd either.

Being such a critical component of the whole stack, it simply will never be
able to trivially swapped out without breaking lots of things. Hence this
bug report is completely moot.

When people like the original bug reporter want to replace the init system,
I assume they know what they are doing so they should be able to clean
up the mess afterwards. Or do you let layman replace the carburetor on
a car themselves without the proper skills and knowledge and then accept
when they complain that something broke in the process?

Really, things like the init system, the C library, the default compiler
and the kernel are *not* user-servicable parts. If you don't know what
you're doing, don't touch them and don't pester the maintainers with
pointless bug reports. Plus, we also clearly decided in 2014 with
the CTTE decision and the follow-up GR by Ian Jackson that we do not
care about alternative init systems.

> As there doesn't seem to be an easy way to get an acceptable runit-init
> package, which replaces the init system by just installing a package, I don't
> see how the current src:runit package can stay in stretch. If someone wants to
> keep it, the best option is probably to remove the runit-init binary package,
> so that the other binary packages can stay. As Roger noted, that would require
> an NMU to do so.

The same problem will apply to sysvinit, openrc, filerc and whatever other
init system we have packaged in Debian as well. I don't want to test that
myself right now, but I am 99% confident that installing the openrc package
will let you with the 'poweroff' and 'reboot' commands broken until you
perform a hard reset.

> I'd be happy to unblock such a change (if it happens in the next few days,
> given the release timing announced in
> https://lists.debian.org/debian-devel-announce/2017/05/msg2.html).

Thanks, but no thanks. I'm happy to provide patches and perform NMUs for
all kinds of packages. But I'm not touching any of these alternative
init systems because I consider them a complete waste of time. There
is simply absolutely no technical justification to ship multiple init
systems. If someone wants to use runit or any of the other init systems,
they should take care of such issues themselves and not bother other
people with that. There are more important issues to work on.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Ivo De Decker]

Hi,

On Fri, May 26, 2017 at 12:04:59PM +0200, John Paul Adrian Glaubitz wrote:
> > > As the init system is a rather fundamental component of a Linux
> > > distribution, it affects many other packages, directly or indirectly
> > > and it's therefore too much of a burden to provide support for all
> > > init systems available in Debian. Although runit is available in
> > > Debian, it does not mean that it has to be fully supported.
> > 
> > If an init system is shipped in a stable release, it has to be supported.
> > Otherwise it should not be in a stable release.
> 
> Well, there is also ulibc being shipped with Debian stable. Yet, when
> someone tries to use it and breaks their system, it's not supported
> either. So, I don't think this policy can be sweepingly applied to
> every package.

There is no package named 'ulibc', so I guess that's a typo. If you meant
uclibc, that package only ships uclibc-source, so installing that doesn't
break anything.

> > > A possible solution would be to modify the runit postinst scripts
> > > in a way that it does not automatically overwrite the symlinks
> > > for the the above commands until the machine has been rebooted
> > > (e.g. by placing a script which is run only once after the system
> > > has been first rebooted with runit) so that the 'poweroff' and
> > > 'reboot' commands are still sent to systemd. However, the lack of
> > > a reply of the runit maintainer to this particular bug report seems
> > > to indicate that there is currently no interest for such a solution.
> > 
> > If the maintainer isn't interested in making sure that this package works as
> > expected, it isn't fit for a stable release...
> 
> I fully agree. However, runit is one of the packages which is not
> automatically removed.

No. But it can be manually removed.

> > > Thus, in order to prevent this bug report from blocking the release
> > > of Debian Stretch, I have reduced its severity to 'normal'. You
> > > are still welcome to propose a patch to address this issue though,
> > > it's just not relevant for the upcoming Debian release.
> > 
> > This is not a good reason to downgrade a bug.
> 
> Again, Debian has decided to adopt systemd as the standard init
> system, the same way we have decided to adopt glibc and the Linux
> kernel as the standard C libraries and kernels.
> 
> You really cannot expect a fundamental component like an init system
> to be easily replace by the end user the same way they can swap their
> default text editor.

Well, in that case there shouldn't be a package that tries to swap the init
system. If there is a package that provides the tools to do so, but lets you
do it on your own, that's a different story. It will still allow you to break
your system, but you can do that with lots of tools (certainly with your text
editor).

As there doesn't seem to be an easy way to get an acceptable runit-init
package, which replaces the init system by just installing a package, I don't
see how the current src:runit package can stay in stretch. If someone wants to
keep it, the best option is probably to remove the runit-init binary package,
so that the other binary packages can stay. As Roger noted, that would require
an NMU to do so.

I'd be happy to unblock such a change (if it happens in the next few days,
given the release timing announced in
https://lists.debian.org/debian-devel-announce/2017/05/msg2.html).

Cheers,

Ivo

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Roger Shimizu]

On Fri, 26 May 2017 11:28:48 +0200
Ivo De Decker  wrote:

> If the maintainer isn't interested in making sure that this package works as
> expected, it isn't fit for a stable release...

FYI. The maintainer cannot respond this for the time being [0].

[0] https://www.debian.org/News/2017/20170417
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1


pgpiyl1AnAYm8.pgp
Description: PGP signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[John Paul Adrian Glaubitz]

Hi!

On Fri, May 26, 2017 at 11:28:48AM +0200, Ivo De Decker wrote:
> If a package leaves the system in a broken state, that is very much release
> critical. So I'm upgrading the bug to serious. It should probably be
> 'critical' (breaks the whole system), but as both are RC, that doesn't matter
> that much.

That is correct and I'm not arguing that per se.

> > As the init system is a rather fundamental component of a Linux
> > distribution, it affects many other packages, directly or indirectly
> > and it's therefore too much of a burden to provide support for all
> > init systems available in Debian. Although runit is available in
> > Debian, it does not mean that it has to be fully supported.
> 
> If an init system is shipped in a stable release, it has to be supported.
> Otherwise it should not be in a stable release.

Well, there is also ulibc being shipped with Debian stable. Yet, when
someone tries to use it and breaks their system, it's not supported
either. So, I don't think this policy can be sweepingly applied to
every package.

> > The fact that it is in Debian is merely of the result of Debian's policy to
> > not limit packages from entering the distribution unless the license or
> > other serious concerns prevent it.
> 
> No. If it's broken, it should not be in a stable release. We can still remove
> this package.

Which hasn't happened yet. The package has been open with an RC bug
for longer than 10 days and yet it wasn't removed from testing.

> > This policy is a result of Debian's decision to adopt systemd as
> > its default init system [1] as well as the follow up general
> > resolution [2] where Debian Developers decided that providing
> > support for alternative init systems was not mandatory.
> 
> > Furthermore, as also already explained, the problem you have run
> > into cannot really be trivially solved as the installing runit
> > does not replace the running instance of systemd with runit so
> > it is to be expected for commands like 'poweroff' and 'reboot'
> > to not work until the machine has been rebooted.
> 
> The fact that problems cannot be trivially solved doesn't mean they are not
> RC. Also, I don't see how it can be 'expected' that reboot doesn't work until
> you reboot. How is this supposed to work? Doing a hard reset of the machine?

I'm rather curious to hear how you suggest to resolve this issue
then. If there was a trivial way, then there'd be a patch for this
already. You cannot replace the running init system without rebooting
the machine, simply because the kernel will panic the moment PID 1
exits.

What the original bug reporter here is asking to work simply cannot
work. You install runit, it removes systemd and overwrites the
symbolic links for 'shutdown' and 'poweroff' while systemd is still
running. It is therefore inevitable that these commands don't work
until you reboot the machine.

And, yes, if a user desires to introduce such a breaking change to
their system, they are on their own. We *did* decide to focus on
systemd after all, so I don't see why we should care if users
intentionally decide to break their systems.

> > A possible solution would be to modify the runit postinst scripts
> > in a way that it does not automatically overwrite the symlinks
> > for the the above commands until the machine has been rebooted
> > (e.g. by placing a script which is run only once after the system
> > has been first rebooted with runit) so that the 'poweroff' and
> > 'reboot' commands are still sent to systemd. However, the lack of
> > a reply of the runit maintainer to this particular bug report seems
> > to indicate that there is currently no interest for such a solution.
> 
> If the maintainer isn't interested in making sure that this package works as
> expected, it isn't fit for a stable release...

I fully agree. However, runit is one of the packages which is not
automatically removed.

> > Thus, in order to prevent this bug report from blocking the release
> > of Debian Stretch, I have reduced its severity to 'normal'. You
> > are still welcome to propose a patch to address this issue though,
> > it's just not relevant for the upcoming Debian release.
> 
> This is not a good reason to downgrade a bug.

Again, Debian has decided to adopt systemd as the standard init
system, the same way we have decided to adopt glibc and the Linux
kernel as the standard C libraries and kernels.

You really cannot expect a fundamental component like an init system
to be easily replace by the end user the same way they can swap their
default text editor.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[John Paul Adrian Glaubitz]

Control: severity -1 normal

On 05/04/2017 07:22 PM, John Paul Adrian Glaubitz wrote:
> I'd be tempted to lower the severity to 'normal'.

Downgrading this now because it is not relevant for the Stretch release.

I also just noticed that you are actually not running Debian but a spin
called "BunsenLabs GNU/Linux", so I'm not sure why you are reporting this
bug to Debian in the first place.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[John Paul Adrian Glaubitz]

Hi Matthew!

>  I ran `apt install runit-init` and then attempted to reboot with
> `/sbin/reboot`, `/sbin/poweroff`, `init 0` & `init 6`, all to no
> effect; no error messages were returned and the exit status of all of
> the commands was zero.

This happens because the computer is still running systemd as the init
process and any runit commands will therefore not work until the computer
has been rebooted with runit as the init system.

I also don't think there is a trivial way to solve this problem. And,
after all, with systemd being the default and supported init system
on Debian as per GR decision, you are on your own anyways when you
decided to switch to one of the alternative init systems.

And since runit is not officially supported to be the init system in
Debian, I don't think this bug qualifies as release critical either.

I'd be tempted to lower the severity to 'normal'.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Matthew T Hoare]

Package: runit-init
Version: 2.1.2-9
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   I ran `apt install runit-init` and then attempted to reboot with
   `/sbin/reboot`, `/sbin/poweroff`, `init 0` & `init 6`, all to no
   effect; no error messages were returned and the exit status of all of
   the commands was zero.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Reintalled systemd-sysv then rebooted into my Arch Linux system,
 chrooted into BunsenLabs then installed the package from the chroot
 and rebooted into that init system.

   * What was the outcome of this action?
   It worked :)
   The same procedure was required to return to systemd as PID1.

-- System Information:
Distributor ID: BunsenLabs
Description:BunsenLabs GNU/Linux (Helium-dev)
Release:x
Codename:   bunsen-helium-dev

Architecture: x86_64

Kernel: Linux 4.10.0-11.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages runit-init depends on:
ii  getty-run  2.1.2-9
ii  libc6  2.24-10
ii  runit  2.1.2-9

runit-init recommends no packages.

runit-init suggests no packages.

-- no debconf information