Bug 221452 - sysutils/consolekit2: session's active state lost when switching between virtual terminals
Summary: sysutils/consolekit2: session's active state lost when switching between virt...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-gnome (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-12 19:19 UTC by Christina Mueller
Modified: 2020-06-11 17:41 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (gnome)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Mueller 2017-08-12 19:19:35 UTC
The session's active state is [still] not 100% accurate with consolekit2 despite the fixes in #202269. I'm using lightdm and xfce4.

When I log in directly from lightdm, ck-list-sessions reports the session as active. However, if I ever switch to a text console and back to the X11 console, the session is reported as "active = FALSE" with the corresponding side effects (not able to mount removable media, ...)

Sometimes, I also have the case that the X11 session remains active even when running ck-list-sessions from a text console. I do not have pam configured to register sessions, thus the only session is the X11 session registered by lightdm, console login or not.

I'm using the text console (kern.vty=sc) and the Nvidia driver in case this makes any difference.

Please let me know if you need additional information or would like me to run tests.

Thanks,
--Christian
Comment 1 Christina Mueller 2017-08-12 19:23:12 UTC
Forgot to mention: I'm on mainline 11.1-RELEASE-p1
Comment 2 rkoberman 2017-08-12 19:32:40 UTC
I can confirm the same issue with 11-STABLE r320665 on amd64 using mate desktop. I have not seen the issue with mounting USB media, though. Probably due to differences between MATE and XFCE4. Also of possible relevance, I don't use a sm to start. I log in to VTY1 and startx:
exec ck-launch-session dbus-launch --exit-with-session mate-session
Comment 3 Jesper Schmitz Mouridsen freebsd_committer 2017-08-25 14:48:11 UTC
I cannot reproduce the problem in comment #2 I've not tried the vty=sc

E.g swithing tty does not invalidate my active x11 session when coming back to /dev/ttyv8 (my x11 tty) from console (CTRL+ALT+F1..F8 neither with xinit or a DM.

How did you both install consolekit2?

I'm at 11.1-RELEASE FreeBSD 11.1-RELEASE
Comment 4 Christina Mueller 2017-08-25 16:43:04 UTC
I've installed consolekit2 via ports using the default config. Most of my packages are installed via pkg, just a few are from ports. In the case of consolekit2, I used ports because it wasn't available as binary package at that point. If you want, I can check and use the binary package if it's available by now.
Comment 5 Gleb Popov freebsd_committer 2020-04-25 12:43:15 UTC
Can't reproduce this on 13-CURRENT with KDE Plasma. Is this PR still relevant?
Comment 6 Christina Mueller 2020-04-25 14:02:18 UTC
It's still an issue for me (FreeBSD 12.1). I'm using XFCE as desktop, however. The problem has not changed: whenever I switch away from the X11 session and back, the X11 session status reported by ck-list-sessions is wrong (inactive).

Thanks,
--Chris
Comment 7 Gleb Popov freebsd_committer 2020-04-25 14:21:33 UTC
I'm not an expert in this field, but it might depend on the video driver used.

To rule this out, can you install KDE Plasma on the same machine you are running XFCE and check if consolekit works in this case?
Comment 8 Christina Mueller 2020-04-26 21:52:31 UTC
I've set up a VM with 13-CURENT and what I believe would make up a KDE Plasma desktop but I can't seem to get it to start any kind of X11 session. This may be me being ignorant to things like Wayland (which I believe to the biggest mistake since Windows 95, pun absolutely intended) but I'm more than happy to try whatever you think would help. Please let me know which (high-level) packages to install on the VM to get a worknig KDE desktop.

Thanks,
--Chris
Comment 9 Gleb Popov freebsd_committer 2020-04-27 07:06:22 UTC
(In reply to chris from comment #8)
plasma5-plasma is a top-level meta-package.

How do you start XFCE? Using login manager or by startx?
Comment 10 Christina Mueller 2020-04-27 13:52:15 UTC
I got it working now - the I was using 13-CURRENT and the packages for the Virtualbox guest additions, including the X11 driver, were initially missing, then had to be rebuilt from prots due to kernel mismatches. The Wayland dependencies pulled in along with plasma5-plasma got me confused - it's still running on X11 per default...

I'll get back as soon as I have the issue reproduced, or confirmed it doesn't exist anymore.

Thanks,
--Chris
Comment 11 Christina Mueller 2020-04-27 17:24:34 UTC
I've reproduced the issue with KDE Plasma on 13-CURRENT:

* Login to KDE session
* Open terminal and run ck-list-sessions; active = TRUE
* Switch to text console (host key + F1 in Virtualbox)
* Login to text console and run ck-list-sessions; it will show the KDE session with active = FALSE (which is correct)
* Switch back to KDE session (host key + F9 in Virtualbox)
* Run ck-list-sessions again; the session did not get reactivated, active = FALSE

Once the session is not active anymore, KDE's "Leave" menu also doesn't provide any options to shut down or reboot the box, just "Lock", "Log Out" and "Switch User".

If you like, I can send you the VM image (15GB, unfortunately, because I had to rebuild the vbox guest additions which comes with gcc, ...) or screen shots, just let me know.

Thanks,
--Chris
Comment 12 Gleb Popov freebsd_committer 2020-04-27 17:33:31 UTC
(In reply to Christina Mueller from comment #11)

> How do you start XFCE? Using login manager or by startx?
Comment 13 Christina Mueller 2020-04-27 17:57:47 UTC
That's actually a little customized. I use lightdm but I had to add a few scripts to /usr/local/etc/X11/xinit/xinitrc.d to get things working the way I like.

Changes to lightdm.conf:
* xserver-allow-tcp=true
* greeter-hide-users=true
* [XDMCPServer] enabled=true

There's one file from consolekit in xinitrc.d, 90-consolekit, which is unchanged. The files I added are:


============================================================================
50-login_conf.sh:

# Lightdm, for one, doesn't process /etc/login.conf and there's no pam module
# to step in, either, thus we have to patch this somehow. For now, we'll
# simply check if BLOCKSIZE is set and, if not, set BLOCKSIZE and PATH
# to sane default values.
if [ -z "$BLOCKSIZE" ] ; then
  PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/local/bin:~/bin
  BLOCKSIZE=K
  export BLOCKSIZE
fi


============================================================================
50-mouse_config.sh:

#------------------------------------------------------------------------------
# Set property for given input device and property name (e.g.
# "Device Accel Constant Deceleration").
#
# NOTE: The expectation is that this won't be called more than a few times
#       during X startup (<10), thus there's no point optimizing or caching
#       anything. Famous last words...
#
xinp_set_prop()
{
  local device="$1"
  local property="$2"
  local value="$3"
  local id
  local pi

  # find device ID
  id=`xinput --list --id-only $device`

  # find property index for $prop
  pi=`xinput --list-props $id | sed -e "s/$property (\([^)]*\).*/\1/" -e t -e d`
  if [ -n "$pi" ] ; then
    xinput --set-prop $id $pi $value
  fi
}

xinp_set_prop sysmouse "Device Accel Constant Deceleration"   1.7
xinp_set_prop sysmouse "Mouse Middle Button Emulation"        0


============================================================================
50-caps_compose.sh:

#!/bin/sh
# configure caps lock as compose key; never needed caps lock, anyway...
setxkbmap -option compose:caps
Comment 14 Christina Mueller 2020-04-27 18:06:00 UTC
Darn, missed that point... my bad.

My last comment was about my "bare metal" box. But I believe we're past that particular setup: the 13-CURRENT VM with KVM shows the same issue and has no modifications whatsoever - everything is right out of the box.

Thanks,
--Chris
Comment 15 Christina Mueller 2020-04-27 18:06:53 UTC
Ugh - replace KVM with KDE :)
Comment 16 Gleb Popov freebsd_committer 2020-04-27 18:29:21 UTC
(In reply to Christina Mueller from comment #15)

Hmm. I'm starting Plasma with startx and my .xinit script consists of

    exec ck-launch-session startplasma-x11

I guess, this is why it works for me. And I think this is what a login manager should do too to register the session with consolekit.

So, I suspect it is LightDM's problem.

Just out of curiosity, can you try SDDM instead of LightDM?
Comment 17 Christina Mueller 2020-04-27 18:33:20 UTC
I'm using sddm in the VM - everything is "KDE" there. No special cofiguration.
Comment 18 Christina Mueller 2020-04-27 18:50:39 UTC
...and the problem still exists on this VM environment
Comment 19 Gleb Popov freebsd_committer 2020-04-27 19:15:25 UTC
What happens if you edit /usr/local/share/xsessions/plasma.desktop so that it execute "/usr/local/bin/ck-launch-session /usr/local/bin/startplasma-x11" instead of "/usr/local/bin/startplasma-x11"?
Comment 20 Christina Mueller 2020-04-27 22:52:59 UTC
This results in a somewhat weird situation as there are two sessions reported by cl-list-sessions on the same VTNr (9), one of which is always "active = FALSE" while the other is always "active = TRUE" even when running ck-list-sessions from a separate text console.

Trying to switch back to the text console a second time resulted in a somewhat unresponsive system - keyboard input was disabled but sending an ACPI shutdown command via Virtualbox still worked.
Comment 21 Gleb Popov freebsd_committer 2020-04-28 08:34:01 UTC
(In reply to Christina Mueller from comment #20)

I see. Well, that means no quick&dirty workaround.

The correct way to fix this is to modify LightDM/SDDM to correctly initiate consolekit session. The problem is that consolekit is, AFAIK, a deprecated API and the "new thing" is logind.

Anyways, I might look into that (for SDDM, at least) but not in near future. For now you can either switch to startx method or report this problem to LightDM's upstream.
Comment 22 Olivier Duchateau 2020-04-29 20:43:09 UTC
(In reply to Gleb Popov from comment #21)

It's not login manager (LightDM, SDDM) to initiate session. It's rather desktop environment. These login managers don't have access methods of org.freedesktop.ConsoleKit.Manager (in any case for Xfce).

ConsoleKit2 and login1 are very close.
Comment 23 Gleb Popov freebsd_committer 2020-05-16 09:42:58 UTC
(In reply to Olivier Duchateau from comment #22)
I'm a bit confused by your comment. The Xsession(5) man says that it initializes X session and is started by either startx or DM. And SDDM does exactly that - it first sources /usr/local/etc/X11/xinit/xinitrc.d/90-consolekit, then Xsession itself and uses $STARTUP variable to run desktop environment. Am I wrong about all that?

Re-reading whole thread, I got an idea that this might be related to kern.vty. IIRC, "sc" is the old thing, maybe it doesn't propagate tty change events when you switch back to X.

Christina, mind firing up that VM again and switching to kern.vty -> vt?
Comment 24 Christina Mueller 2020-05-16 12:01:56 UTC
Unfortunately, the VM died with disk image corruption - it appears Virtualbox has a bug when using multiple CPU cores (16 in my case) to recompile the world with debug info in combination with a dynamic VDI disk image...

I've just tried to reproduce the issue with a 12.1-RELEASE VM but couldn't - the KDE session remains active all the time, even when switching to the console, and independenly of kern-vty=sc/vt. A former try with 12.1-RELEASE, XFCE and kern-vty=vt actually showed it working properly, very confusing.

I've also tried kern.vty=vt on my physical system (12.1-RELEASE) but the behavior did not change - once I switch away from the X desktop the session becomes inactive and won't activate when switching back to the X desktop. I need to use kern.vty=sc, though, because nvidia-driver is incompatible to vt.

I'll try and set up the 13-CURRENT VM again and reproduce the issue.
Comment 25 Christina Mueller 2020-05-25 15:53:49 UTC
Sorry for the delay, things got into the way. I've now reproduced the issue on a new VM with 13-CURRENT and KDE/SCCM with kern.vty=vt:

This is with KDE on the screen after switching between various VTs:
chris@ck-test:~ $ sysctl kern.vty
kern.vty: vt
chris@ck-test:~ $ ck-list-sessions
Session2:
        unix-user = '1001'
        realname = 'Christina Mueller'
        seat = 'Seat1'
        session-type = 'unspecified'
        session-class = 'user'
        session-state = 'online'
        active = FALSE
        x11-display = ':0'
        x11-display-device = '/dev/ttyv8'
        display-device = '/dev/   ?   '
        remote-host-name = ''
        is-local = TRUE
        on-since = '2020-05-25T15:42:38.148925Z'
        login-session-id = ''
        XDG_RUNTIME_DIR = '/var/run/user/1001'
        VTNr = '9'

One thing worth noting is that just switching from the X VT to VT #1 doesn't trigger the problem. the X session is still reported as active. Even logging in on VT #1 did not change anything. switching to VT #2/3/4 and back finally made the X session inactive and it did not reactivate when switching back to it.

I haven't noticed this before but this could mean that consolekit2 misses some of the VT switches and this might be part of the problem.

I'll recompile the installed packages with debug info and see if I can track this down but debugging dbus-launched services is a pain as dbus tends to start new instances almost at will (I guess it's not happy with the delays incurred by debugging).
Comment 26 Christina Mueller 2020-05-25 15:54:54 UTC
Sorry, SDDM, not SCCM :)
Comment 27 Gleb Popov freebsd_committer 2020-05-25 16:07:30 UTC
(In reply to Christina Mueller from comment #25)
> debugging dbus-launched services is a pain as dbus tends to start new instances almost at will 

You can remove /usr/local/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service file, this will make dbus unaware of consolekit presence. Then you can start your own consolekit under gdb and things should work as usual.
Comment 28 Christina Mueller 2020-05-25 16:08:49 UTC
Thanks for that!
Comment 29 Olivier Duchateau 2020-05-25 19:53:09 UTC
It's SSDM problem! I'm using Xfce with LightDM and session properties are fine.

With Xorg session, I get

>gdbus introspect -y -d org.freedesktop.ConsoleKit -o /org/freedesktop/ConsoleKit/Session2 --only-properties
>node /org/freedesktop/ConsoleKit/Session2 {
>  interface org.freedesktop.ConsoleKit.Session {
>    properties:
>      readonly u unix-user = 1001;
>      readonly u user = 0;
>      readonly (so) Seat = ('Seat1', '/org/freedesktop/ConsoleKit/Seat1');
>      readonly s session-type = 'unspecified';
>      readonly s session-class = 'user';
>      readonly s session-state = 'active';
>      readonly s remote-host-name = '';
>      readonly s display-device = '/dev/   ?   ';
>      readonly s x11-display = ':0';
>      readonly s x11-display-device = '/dev/ttyv8';
>      readonly u VTNr = 9;
>      readonly b active = true;
>      readonly b is-local = true;
>      readwrite b idle-hint = false;
>      readonly b LockedHint = false;
>  };
>};

The object path (/org/freedesktop/ConsoleKit/Session2) is found with following command:

>gdbus introspect -y -d org.freedesktop.ConsoleKit -o /org/freedesktop/ConsoleKit

If I switch to VT #2 (or another) I get:

>gdbus introspect -y -d org.freedesktop.ConsoleKit -o /org/freedesktop/ConsoleKit/Session2 --only-properties
>node /org/freedesktop/ConsoleKit/Session2 {
>  interface org.freedesktop.ConsoleKit.Session {
>    properties:
>      readonly u unix-user = 1001;
>      readonly u user = 0;
>      readonly (so) Seat = ('Seat1', '/org/freedesktop/ConsoleKit/Seat1');
>      readonly s session-type = 'unspecified';
>      readonly s session-class = 'user';
>      readonly s session-state = 'online';
>      readonly s remote-host-name = '';
>      readonly s display-device = '/dev/   ?   ';
>      readonly s x11-display = ':0';
>      readonly s x11-display-device = '/dev/ttyv8';
>      readonly u VTNr = 9;
>      readonly b active = false;
>      readonly b is-local = true;
>      readwrite b idle-hint = false;
>      readonly b LockedHint = false;
>  };
>}

And when I switch back to VT#9 session-state is still **active**.
Comment 30 Samy Mahmoudi 2020-06-09 22:08:02 UTC
Just in case the following can help: are you aware of bug 243988?