Slackware-Current: After update, Switch User, Suspend, Restart, Shut Down buttons are greyed out.
 

I have just updated my Slackware-Current system.
The first line of the ChangeLog.txt is:
Everything was updated, except for the kernel packages, which are still on version 4.19.25 (instead of the updated 4.19.26).

I’m running the XFCE desktop, and my display manager is XDM.
To my surprise, the “Switch User”, “Suspend”, “Restart” and “Shut Down” buttons are now greyed out, and are no longer active.
The “Lock Screen” and “Log Out” buttons, on the other hand, continue to function normally.

Is there anything I can do to diagnose this issue, or, better yet, to resolve it?

I'm always sudo rights so maybe that is it. check that, and polkit -- I'd have to dig for it. so maybe someone else I am sure knows more as I do not use xfce4 much anymore. but a terminal when I want to reboot, and my power button when I want to shut down.

I'd check that /var/run/ConsoleKit/ looks correct and that /var isn't out of space. I did run into the same issue once when I tried to move CK2's run directory into /run as recommended by upstream.

The very same happened to me, running the MATE desktop - the shutdown/restart/suspend options are gone from the main menu.
Also, the slackware login screen is different: white fields for username and password, and nothing shows up when entering username.

EDIT: Downgraded xdm to version 1.1.11 which "solved" the problem. So there must be something in the latest package causing this.

i used MATE 1.21.x (development version) and it still worked as it used to be in 1.20.x

Switching to KDM, instead of XDM, also works.
Hence, I confirm that something in the latest XDM package must be causing this issue.

So maybe I'll be able to upgrade xdm when the stable MATE-1.21 packages are ready (I can't find the energy to build them on my own right now). Still, the OP had the same issue running the xfce desktop... and it definitely has to do with the xdm-1.1.12 upgrade.

I haven't a clue to what it could be, though. I do get a few error messages in /var/log/xdm.log and in ~/.xsession-errors, but none of them fatal and the log files have the same content no matter if I have xdm-1.1.11 or -1.1.12 installed.

And of course I'm not running a clean Slackware install but -multilib and a lot of 3rd party stuff which doesn't help when trying to pinpoint the cause.

Well, I just upgraded to all the latest packages on an old netbook running -current 32 bit and xfce and encountered just what luvr described. Downgraded to xdm-1.1.11 and everything is back to normal.
Again, it's not a 100 % fresh and clean slackware install, but on this netbook there are very few 3rd party programs or other tweaks.
It's nev4ertheless odd that it seems as only two -current users experience this?

From the -current changelog 2019-03-05 22:54:

Guess the thread can be marked as SOLVED.

I'd don't know about "SOLVED". "AVOIDED" maybe.

The problem looks to be consolekit.

With the new xdm a org.freedesktop.ConsoleKit.Manager.CanRestart call returns 'false' even outside of xfce. You can check it with:
dbus-send --system --print-reply --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.CanRestart


The dbus-send works, it just returns 'false'.

I just tried it in an fvwm session started by both the new xdm and by startx and the results are the same as with xfce. Returns 'true' from startx, returns 'false' from xdm.

Now, in the past I've seen the following construct in xinitrc:
cause problems when things are started under xdm, but in this case changing it to:
... and having startxfce4-with-dbus launch dbus using the eval method doesn't help. But, the consolekit service is on the system rather than session bus anyway. Still, it was worth a try.

So, I guess the next question is how does consolekit decide who can do what, and why is xdm interfering with that.

I've been having to circumvent getting dbus via a login manager by creating a separate script that calls to dbus first then to the desktop I am using to start, in lue of what use to work by putting it in the autostart file, though this is for auto mount usb ports, it is still related to dbus.

[SOLVED] Dbus does not start xfce4-notfiyd daemon

SLiM fails to start xfce4 because of some weird dbus error

... and that thought led me to the cause!

The session is being registered twice! My guess is once by xdm, and then again by xinitrc. This then causes the policykit service to decide that multiple users are logged in and disable the restart/reboot options.

Removing the ck-launch in xinitrc confirms it. Now, we just need to find a fix that doesn't break startx.

Update:
Removing the ck-launch from xinitrc and adding it to startx instead is one possible route and has some appeal. Alternatively, xdm has a -noconsolekit command option which might be easier to implement, but I still find the first choice appealing.

Update2: on seconds thoughts I suspect ck-launch needs the display already running so startx is out.

Update3: Setting DESKTOP_SESSION from /etc/X11/xdm/Xsession might do it. If other Display Managers set that then taking that route would keep things consistent.


I decide to go with the 3rd option here: setting/exporting DESKTOP_SESSION from Xsession. Working fine.

While we're on the subject, Here's a cleaned up /etc/X11/xdm/Xsession file I've been using for a while now, that I've just fixed for this issue.
Important note: Unlike the existing Slackware Xsession file, it doesn't call /etc/profile (as I find that rather ugly), instead it just runs /etc/xprofile so if you want everything that /etc/profile does to still be done when you login to X then copy or symlink it to /etc/xprofile. I didn't, which is why I created a separate /etc/xprofile. Anyway, this approach gives you that flexibility.

File is attached. If Pat wants to adopt this, then that would suit me down to the ground as it'd be one less thing I have to change. :)

Hello,

Just noticed that an ldd on xdm 1.1.12 returns a reference to libck-connector.so.0 which is not the case for xdm 1.1.11.

I looked at the last commits for xdm (available here) and found that for xdm 1.1.12 there was the file source/x/x11/configure/xdm with the following content:


The autoreconf is required because of consolekit patch. This patch is used for both xdm versions, but the file source/x/x11/configure/xdm does not exist for 1.1.11 and the default configuration file source/x/x11/configure/configure is used instead, but it does not run autoreconf, and thus, xdm 1.1.11 is not linked to libck-connector.so.0.

When xdm 1.1.11 is configured with source/x/x11/configure/xdm, it is linked to libck-connector.so.0, and exposes the same issue as xdm 1.1.12 (i.e. shutdown/suspend/.. buttons greyed).

Hope this helps.

--
SeB

Hello,

I looked at xdm-consolekit.patch and noticed that it defines the environment variable XDG_SESSION_COOKIE when a session is sucessfully opened, and before the ~/.xession is executed :

Therefore, I think that ~/.xsession should be changed as below :

Edit: So to have a working xdm (1.1.11 or 1.1.12) with working consolekit support, it is required to :

1. apply the patch xdm-console.patch
2. run "autoreconf -vif" before ./configure
3. provide .xsession files with the change above

--
SeB