sysvinit: Can't power off jessie from gnome poweroff menu

[Simon McVittie]

On Sat, 29 Dec 2018 at 18:34:50 +0000, Dmitry Bogatov wrote:
> I have no knowledge about DE, but maybe gnome team could help?
> 
> Dear gnome maintainers, what command is actually invoked when power-off
> button is pressed?

No command is invoked: it's done via IPC. gnome-shell asks gnome-session
to power off, using the D-Bus session bus. I'm fairly sure gnome-session
asks systemd-logind (or potentially a compatible replacement like elogind)
to power off, using the D-Bus system bus, although I can't immediately
find the specific code that does this. This will require a working
logind implementation of some sort, a working polkit (policykit-1),
and a working D-Bus system bus.

You could find the exact D-Bus system bus message that does this by
running `dbus-monitor --system` as root, then attempting to shut
down. Having found the relevant method call, it would probably be
straightforward to make an equivalent call as a command-line reproducer
by passing the right command-line arguments to dbus-send(1), gdbus(1)
or a similar tool.

If the bug reporter has systemd-shim installed and expects that to
provide their working logind, then the root cause is very likely to be:

* systemd-logind is designed to be used with a matching version of
  systemd-as-pid-1
* systemd-shim is designed to emulate systemd-as-pid-1 just well enough
  to make systemd-logind work on a sysvinit system, even though it wasn't
  designed for that
* systemd-shim is unmaintained and doesn't actually emulate
  a recent systemd-as-pid-1 well enough to make a recent systemd-logind
  work (it has been removed from testing and unstable for this reason)

My understanding is that systemd-logind + systemd-shim + sysvinit might
have worked in jessie, but is in an unknown/untested state in stretch,
and is known not to work in buster.

If you intend for sysvinit support in Debian to be sufficiently broad
that it includes the ability to run desktop environments with full
or nearly-full functionality, I'd recommend testing with a desktop
environment like GNOME or KDE (possibly installed in a virtual machine
if you don't want it on your host system).

Using an autopkgtest to verify that the intended functionality
continues to be provided, perhaps similar to systemd's
debian/tests/boot-and-services, would also be a good idea; that would
detect regressions.

    smcv