Reassigned to @fritsd

I'll take a look at it, if I don't report back here by next weekend please reassign it to someone else.

I have the same issue, and in the source I looked at liblightdm-gobject/power.c where it seems first a logind function gets tried out, and if that fails, a consolekit function (see e.g. the reboot function, lightdm_restart() ).

It's really quite a labyrinth of permissions, libraries and middle-ware :-) but I'm trying to understand it.

Thanks Frits! good luck with that. It is rather important issue for desktop usage.

I've included @dimkr (loginkit dev) as he may have good answers.

Jaromil, Dima, I think that lightdm_gtk_greeter is where the bug shows up (line 864), and liblightdm-gobject-1-0 (from lightdm) is maybe where the faulty code is. Dima it sounds like you're much more qualified to find this bug :-) I'll look again today.

It looks like it goes wrong on the other side of dbus, on the consolekit side:

I've traced the error to liblightdm-gobject-1-0: I can see that it tries to call the "CanRestart" method from ck_proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SYSTEM, G_DBUS_PROXY_FLAGS_NONE, NULL, "org.freedesktop.ConsoleKit", "/org/freedesktop/ConsoleKit/Manager", "org.freedesktop.ConsoleKit.Manager", NULL, error);

that returns TRUE, and then r = g_dbus_proxy_call_sync(ck_proxy, function, NULL, G_DBUS_CALL_FLAGS_NONE, -1, NULL, error);

I think that fails, and then lightdm_gtk_greeter doesn't make the "reboot" button in the power menu (top right corner). probably same for the other functions suspend, hibernate etc, I just looked only at reboot.

So I think lightdm asks "dbus, can I reboot?", then dbus says "I'll ask consolekit", and consolekit says "no.", and lightdm_gtk_greeter says "ok i will hide the reboot menu button then"

And if I do qdbus --system org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager on my (half-wheezy half-jessie no-systemd) system, then it contains (with 21 other methods) ... method bool org.freedesktop.ConsoleKit.Manager.CanRestart() ... method void org.freedesktop.ConsoleKit.Manager.Restart()

so that seems to me like ConsoleKit is registered with dbus and running: root 3752 0.0 0.1 2096108 4004 ? Sl 11:29 0:00 /usr/sbin/console-kit-daemon --no-daemon

I've been looking at consolekit now.. it calls a function from policykit, polkit_authority_check_authorization()

That one is in package policykit-1 file src/polkit/polkitauthority.c

It's an asynchronous function that eventually returns null (meaning "not authorized" i presume) The function has a series of checks that are all OK except for the last one:

g_dbus_proxy_call (authority->proxy, "CheckAuthorization", g_variant_new ("(@(sa{sv})s@a{ss}us)", subject_value, action_id, details_value, flags, data->cancellation_id != NULL ? data->cancellation_id : ""), G_DBUS_CALL_FLAGS_NONE, G_MAXINT, /* no timeout */ cancellable, (GAsyncReadyCallback) check_authorization_cb, data);

but I'm getting in a bit above my depth here... grmbl couldn't they make this stuff a bit easier..

on my (admittedly weird) system there are no DBus thingies that have a method "CheckAuthorization", possibly this is the root cause?

spec seems to be: http://www.freedesktop.org/software/polkit/docs/latest/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html

Yes - indeed, sounds like a classic polkit issue. I'll take a look.

Found something interesting. I restarted LightDM while running /usr/lib/policykit-1/polkitd via SSH (so I can see its output):

Error loading /var/run/ConsoleKit/database: Error statting file /var/run/ConsoleKit/database: No such file or directoryUsing authority class PolkitBackendLocalAuthority

And this:

root@devuan:/home/devuan# apt-cache depends policykit-1
policykit-1
  Depends: libc6
  Depends: libglib2.0-0
  Depends: libpam0g
  Depends: libpolkit-agent-1-0
  Depends: libpolkit-backend-1-0
  Depends: libpolkit-gobject-1-0
  Depends: dbus
  Breaks: <gdm3>

policykit-1 does have a ConsoleKit dependency, according to https://packages.debian.org/jessie/policykit-1 . Maybe the problem is http://anonscm.debian.org/cgit/pkg-utopia/policykit.git/commit/?id=9d4e93b713abefbbb5ea623515f7e9f9e9b1ea69 .

@jaromil - if ConsoleKit support was replaced with systemd, we should fork it. Am I missing something?

EDIT: grrr ... sometimes I hate GitLab, it hides the policykit-1 package because I don't have permissions. We need to change "consolekit [!linux-any]" to "consolekit", in https://git.devuan.org/packages-base/policykit-1/blob/master/debian/control and that should do.

EDIT 2: confirmed. Starting ConsoleKit and restarting polkitd restores the shutdown and restart buttons in both Xfce and LightDM.

Status changed to closed

About the hiding of projects of which one is not member... yea that's annoying.

Let us know if you find any solution to that.

Dima: I confirm, installing policykit-1 solved it!

I installed policykit-1 and libpolkit-backend-1-0 (0.105-3) and voil\xc3\xa0 qdbus sees the method org.freedesktop.PolicyKit1.Authority.CheckAuthorization, and the buttons in the lightdm-gtk-greeter power menu appear.

It's a bit strange that ConsoleKit calls a function in PolicyKit while PolicyKit reads a ConsoleKit database. Oh well.. If it's in /var/run then my first reaction would be that the boot order must be adapted, however I learned today that ConsoleKit doesn't get started with an initscript, it gets started by dbus.

Does anyone know if dbus starts the things in /usr/share/dbus-1/system-services in any particular order?? or how to configure that??? Otherwise, we have a 50% chance of the same problem on every boot.

I though I had got rid of policykit-1 for a reason but unfortunately I didn't document properly why.

I think I should add a Recommends: policykit-1 to lightdm, agreed? maybe even a Depends: because shutdown from the starting screen is a task most users expect to be able to do.

As an added bonus, my LXDE desktop now suddenly has two new buttons in its logout menu: Shutdown and Reboot :-)

Each D-Bus service is started when something calls a method it provides, so it should work, unless their startup sequences deadlock (e.g ConsoleKit starts but registers itself only after it calls a polkit method, or vice-versa).

There's no reason to add a policykit-1 dependency to LightDM, because it depends on ConsoleKit.

Status changed to reopened

Bad news - this bug re-appears when logind is running. Need to investigate why this happens and why logind is started.

@fritsd - could be related to the Debian bug you linked to at the top.

Found something interesting: LightDM checks whether logind is present by connecting to it. The connection succeeds if logind is installed and that's the case on Devuan, because the entire systemd is contained in one package. However, xfce4-panel performs the right check (like all other packages) - it tries to access /run/systemd/seats. That's why it works.

To sum it up - installing ConsoleKit enables the shutdown and reboot buttons in Xfce, but not in LightDM. The latter works only after /lib/systemd/systemd-logind is deleted.

The only solution I see is patching LightDM, to add a LOGIND_RUNNING() check before it starts logind. More ideas?

Oh I see: lightdm is a bit "quantum mechanical" because observing whether you can connect to logind means that it gets started on-demand by dbus (as you wrote in your previous comment) so the act of observing disturbes the state :-)

I'll see how xfce4-panel does it and then I'll patch lightdm accordingly. I'll need handholding to push the patch upstream to devuan. Unless you've already done it.

BTW Dima do you know if logind is the only "provider" of shutdown functionality or are there different ones? (I'm a bit surprised upower doesn't provide it, because of the name)

Dima I can't find any reference to /run/systemd/seats in xfce4-panel 4.8.6 or libxfce4ui 4.8.1, can you point out where you saw it (I probably should look at the jessie version not the wheezy version).

I must say I like the situation where (1) the lightdm buttons work AND (2) /lib/systemd/systemd-logind is deleted! I also can't find /run/systemd (and /var/run is symlink to /run) anywhere here..

Yes, connecting to logind disturbes the existing state, because that starts logind, which creates /run/systemd/seats. logind support was introduced after Xfce 4.10 AFAIK, so you won't see this in Wheezy. I was able to spot xfce4-panel's attempts to check whether logind is present, via strace.

I don't think patching LightDM is a good solution, because that means it no longer works with the logind backend. The DM is supposed to be the first time something uses logind and if we prevent this, funny things will happen (e.g a DM that uses ConsoleKit and a DE that uses logind).

Switching to SLiM by forking tasksel is the best short-term solution, IMHO.

I have to make a summary or I'll get lost in the details here. You have to inform me if I'm talking crap in the following summary.

As I understand it today:

• a Display Manager gets started on boot in runlevel 5 to allow the person sitting in front of the (a?) console (nowadays called a "seat" apparently) to start an X11 session. This is a "login program" so must be small and secure because it hands over system resources (mouse, keyboard, screen) from root to a normal user. It also needs privilege to shutdown or reboot or hibernate at the end of the working day when the user has logged off.

• we are currently using a combination of lightdm, lightdm-gtk-greeter, PAM, dbus, consolekit, policykit-1, upower and systemd-logind to try to achieve this and fail (because the lightdm-gtk-greeter shutdown buttons are greyed out).

• dbus is a conduit for the shutdown etc. commands: lightdm-gtk-greeter and lightdm ask dbus to wake up consolekit and submit the "may_i_shutdown" command, and if the user presses the shutdown button, "shutdown" command. This happens in the liblightdm-gobject-1 module of lightdm, file power.c. Each command is subtly different. table: how each action is processed, the numbers indicate which one is tried first, (1), second etc.

action consolekit logind upower can_suspend? - 1 2 suspend - 1 2 can_hibernate? - 1 2 hibernate - 1 2 can_restart? 2 1 - restart 2 1 - can_shutdown? 2 1 - shutdown 2 1 -

The "back end" of dbus can try to start up daemons to perform these requests. The lightdm DM does this by always first trying out a logind request, and if that fails (because logind is not installed) either consolekit or upower depending on the requested function.

Consolekit handles the "reboot" request by sending a policykit-1 dbus request, and policykit-1 handles it by looking up a file owned by consolekit, so these are mutually dependent. I haven't looked at upower yet.

logind has been incorporated into PID eins for a long time so we should try to avoid dependencies on it.

It would be easy to patch liblightdm-gobject-1-0 to change the priority, i.e. so that first consolekit and upower are tried instead of logind. That would mean logind never gets tried out on a system with both consolekit and upower installed, so we lose that systemd dependency.

I understand from your (Dima's) previous comment that that would be annoying for devuanistas who want to use the systemd-logind backend, because their Desktop Environment session after successful login would not yet have a properly initialised logind daemon to talk to.

Now I'm still learning all of this; but what kind of functionality does logind provide in a logged-in user's session, and can we just "take the damage" and declare lightdm-devuan a Conflicts: libsystemd-login0 or something?

I looked at the code of SLiM and it looks fantastically small and simple, but since the issue is on the "back-end" of dbus, I mean the daemons that provide the shutdown etc. functionality, wouldn't any other DM program have the same issue?

well that table didn't work out ok.. I meant:

table: how each action is processed, the numbers indicate which one is tried first, (1), second etc.

action	consolekit	logind	upower
can_suspend?	-	1	2
suspend	-	1	2
can_hibernate?	-	1	2
hibernate	-	1	2
can_restart?	2	1	-
restart	2	1	-
can_shutdown?	2	1	-
shutdown	2	1	-

I think you got it right.

I think we're fine with a situation where Xfce uses ConsoleKit and LightDM uses logind. However, the only thing I don't understand is why the can_* methods tell LightDM that logind cannot perform power-management actions. Maybe there's a dependency on systemd being PID 1.

Well I've prepared a patch to lightdm, that tries out ConsoleKit or Upower first and logind last, and "it works for me" (I don't have logind installed).

But can anyone please say again if we still really need to take this action, or if this bug can be closed for the moment.

I also want to comment that it seems awfully quiet on the mailinglist and here; is everything allright??

IMHO, we shouldn't patch LightDM, because we want neutrality. We want init freedom: the ability to use either sysvinit or systemd, but without getting our hands dirty unless that's the only way to make crucial packages work with sysvinit. By "crucial", I mean things like D-Bus.

Currently, LightDM prefers logind, but patching it so it prefers ConsoleKit could be a source of potentials bugs that affect only those who switch to systemd. IMHO, the situation is bad in either way.

I suggest that we switch to SLiM or MDM and forget about fixing LightDM for Devuan.

2c

I concur to not fix LightDM at the moment in Devuan, also because I'm not sure it's broken :-) but I have made the patch, so if you or anyone change your mind it can be applied quickly.

Dima I respect your comment about neutrality.

I don't have any specific preference for which DM we're going to use, personally.

I'm going to close this bug now, because from what I understand, there is no problem in lightdm or lightdm-gtk-greeter. It is a problem in systemd-logind (quelle surprise). I doubt whether that bug is therefore "release-critical" for Devuan. (I don't doubt that it's an annoying bug for people who install both Devuan and systemd).

If I misunderstood then please open this bug again.

So currently we have the situation that lightdm works, including shutdown buttons, but it depends on ConsoleKit and policykit-1 and Upower, and you have tested a situation where the shutdown buttons don't work properly when systemd (logind) is installed.

Sounds like a problem in systemd -- I have a great idea: if that bug isn't fixed, let us release Devuan Jessie without systemd!

;-D

Status changed to closed

@fritsd do you have the patch somewhere? it is actually desirable to have, at least to learn from your approach and evaluate.

In Devuan we do not go for neutrality, we go for an OS that works perfect without systemd first and foremost.

Status changed to reopened

pff.. I had forgotten about that one.. I shall have to dig a bit

Got it. Dima Krasner knows more about it. This patch is from 2015-03-15 and NOT VERY WELL TESTED. I'm not very familiar with GNOME, PolicyKit or ConsoleKit. patch.power

thanks. This issue is a useful reference and having also the patch we can be sure the door is still open for this solution. But first @CenturionDan is going to look into other options to solve this problem without changing code, but removing dependencies.

Hello to everyone. Thanks for bringing out Devuan. Concerning LightDM, placing two files at /var/lib/polkit-1/localauthority/10-vendor.d/ (org.freedesktop.consolekit.pkla and org.freedesktop.upower.pkla - attached here) has helped me to solve the issue related to lightdm (reboot/shutdown - I haven't yet checked for suspend/hibernate). Checked with the latest version of LightDM (v1.22.0), which I have compiled in Devuan Jessie.

org.freedesktop.consolekit.pkla org.freedesktop.upower.pkla

This issue is still persistent on lightdm with ascii. Power off, restart all grayed out. I have elogind and other dependencies installed (no consolekit). ascii release notes suggests it supports Cinnamon desktop environment and recommends lightdm+cinnamon. Please ask, if any logs are needed. BTW, LXDM works fine with poweroff and reboot menu available.

:~# dpkg -l | egrep "consolekit|elogind|libpam|policykit|polkit|eudev"
ii  elogind                              234.4-2                            amd64        user, seat and session management daemon
ii  eudev                                3.2.2-13                           amd64        /dev/ and hotplug management daemon
ii  gir1.2-polkit-1.0                    0.105-18+devuan2.11                amd64        GObject introspection data for PolicyKit
ii  libelogind0:amd64                    234.4-2                            amd64        user, seat and session management library
ii  libeudev1:amd64                      3.2.2-13                           amd64        libeudev shared library
ii  libpam-cap:amd64                     1:2.25-1                           amd64        POSIX 1003.1e capabilities (PAM module)
ii  libpam-elogind:amd64                 234.4-2                            amd64        elogind PAM module
ii  libpam-gnome-keyring:amd64           3.20.0-3                           amd64        PAM module to unlock the GNOME keyring upon login
ii  libpam-modules:amd64                 1.1.8-3.6                          amd64        Pluggable Authentication Modules for PAM
ii  libpam-modules-bin                   1.1.8-3.6                          amd64        Pluggable Authentication Modules for PAM - helper binaries
ii  libpam-runtime                       1.1.8-3.6                          all          Runtime support for the PAM library
ii  libpam0g:amd64                       1.1.8-3.6                          amd64        Pluggable Authentication Modules library
ii  libpolkit-agent-1-0:amd64            0.105-18+devuan2.11                amd64        PolicyKit Authentication Agent API
ii  libpolkit-backend-1-0                0.105-18+devuan2.11                all          PolicyKit Authorization API
ii  libpolkit-backend-1-0-elogind        0.105-18+devuan2.11                all          PolicyKit Authorization API
ii  libpolkit-backend-elogind-1-0:amd64  0.105-18+devuan2.11                amd64        PolicyKit backend API
ii  libpolkit-gobject-1-0                0.105-18+devuan2.11                all          PolicyKit Authorization API
ii  libpolkit-gobject-1-0-elogind        0.105-18+devuan2.11                all          PolicyKit Authorization API
ii  libpolkit-gobject-elogind-1-0:amd64  0.105-18+devuan2.11                amd64        PolicyKit Authorization API
ii  policykit-1                          0.105-18+devuan2.11                amd64        framework for managing administrative policies and privileges
ii  policykit-1-gnome                    0.105-6                            amd64        authentication agent for PolicyKit
ii  udev                                 1:3.2.2+devuan2.11                 amd64        Transitional package for eudev

there's no such issue in current lightdm + elogind versions in beowulf (+MATE, amd64). maybe these versions can be backported to ascii too(?).

dpkg -l | egrep "lightdm|consolekit|elogind|libpam|policykit|polkit|eudev"
ii  elogind                               239.3+20190131-1                   amd64        user, seat and session management daemon
ii  eudev                                 3.2.7-3                            amd64        /dev/ and hotplug management daemon
ii  libelogind0:amd64                     239.3+20190131-1                   amd64        user, seat and session management library
ii  libeudev1:amd64                       3.2.7-3                            amd64        libeudev shared library
ii  liblightdm-gobject-1-0:amd64          1.26.0-3                           amd64        simple display manager (Gobject library)
ii  libpam-cap:amd64                      1:2.25-1.2                         amd64        POSIX 1003.1e capabilities (PAM module)
ii  libpam-elogind:amd64                  239.3+20190131-1                   amd64        elogind PAM module
ii  libpam-gnome-keyring:amd64            3.28.2-2                           amd64        PAM module to unlock the GNOME keyring upon login
ii  libpam-modules:amd64                  1.1.8-4                            amd64        Pluggable Authentication Modules for PAM
ii  libpam-modules-bin                    1.1.8-4                            amd64        Pluggable Authentication Modules for PAM - helper binaries
ii  libpam-runtime                        1.1.8-4                            all          Runtime support for the PAM library
ii  libpam0g:amd64                        1.1.8-4                            amd64        Pluggable Authentication Modules library
ii  libpolkit-agent-1-0:amd64             0.105-25+devuan1                   amd64        PolicyKit Authentication Agent API
ii  libpolkit-backend-1-0                 0.105-25+devuan1                   all          PolicyKit Authorization API
ii  libpolkit-backend-elogind-1-0:amd64   0.105-25+devuan1                   amd64        PolicyKit backend API
ii  libpolkit-gobject-1-0                 0.105-25+devuan1                   all          PolicyKit Authorization API
ii  libpolkit-gobject-elogind-1-0:amd64   0.105-25+devuan1                   amd64        PolicyKit Authorization API
ii  lightdm                               1.26.0-3                           amd64        simple display manager
ii  lightdm-gtk-greeter                   2.0.6-1                            amd64        simple display manager (GTK+ greeter)
ii  mate-polkit:amd64                     1.20.2-1                           amd64        MATE authentication agent for PolicyKit-1
ii  mate-polkit-bin                       1.20.2-1                           all          MATE authentication agent for PolicyKit-1 (executable wrapper script)
ii  mate-polkit-common                    1.20.2-1                           amd64        MATE authentication agent for PolicyKit-1 (common files)
ii  policykit-1                           0.105-25+devuan1                   amd64        framework for managing administrative policies and privileges
rc  udev                                  1:3.2.7+devuan1.1                  amd64        Transitional package for eudev

@xinomilo I'm on Beowulf and I do see this issue :(

Following @zen-subz 's example, I've fixed this by creating a
/etc/polkit-1/localauthority/90-mandatory.d/enable-reboot-poweroff.pkla
containing

[Enable LightDM reboot and poweroff (logind)]
Identity=unix-user:*
Action=org.freedesktop.login1.reboot;org.freedesktop.login1.power-off
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Correction, please see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932047