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
Forgot to mention: I'm on mainline 11.1-RELEASE-p1
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
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
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.
Can't reproduce this on 13-CURRENT with KDE Plasma. Is this PR still relevant?
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
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?
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
(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?
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
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
(In reply to Christina Mueller from comment #11) > How do you start XFCE? Using login manager or by startx?
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
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
Ugh - replace KVM with KDE :)
(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?
I'm using sddm in the VM - everything is "KDE" there. No special cofiguration.
...and the problem still exists on this VM environment
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"?
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.
(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.
(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.
(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?
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.
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).
Sorry, SDDM, not SCCM :)
(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.
Thanks for that!
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**.
Just in case the following can help: are you aware of bug 243988?
From the MATE Desktop 1.24 release note: "If your system doesn’t, uh, support systemd you might be interested in knowing that we’ve added support for elogind to both the MATE Screensaver and the MATE Session." https://mate-desktop.org/blog/2020-02-10-mate-1-24-released/ Might be a good idea to use elogind if no one can fix sysutils/consolekit2 problem. https://github.com/elogind/elogind
(In reply to Eric Turgeon from comment #31) elogind is of course better idea, as it is at least maintained, unlike consolekit. However, elogind needs porting, and after giving it a quick look, I suspect it is far from trivial.
FWIW I cannot reproduce the issue with ssdm 18.1_4 on 12.1
- If I **reboot** and go to text and start Plasma, so the very very first session (and sometimes a later session, I haven't got a good handle on this), it does change, here's my second session after a reboot: Session2: unix-user = '1001' realname = 'Adriaan de Groot' seat = 'Seat1' session-type = 'unspecified' session-class = 'user' session-state = 'active' active = TRUE x11-display = ':0' x11-display-device = '/dev/ttyv8' display-device = '/dev/ttyv1' remote-host-name = '' is-local = TRUE on-since = '2021-05-16T21:31:18.505346Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1001' VTNr = '9' - Sometimes, from the text console like I just described, the session will be active, but a switch to text-mode sets it to not-active, and then switching back again to X11 doesn't do anything. It remains not-active. Like I said, I don't have a good handle on this. Logging out, goting to root and running `service sddm onestart` to get SDDM: - Log in from SDDM to a Plasma X11 session with the "regular" Plasma session selected, then the session is not marked active: Session5: unix-user = '1001' realname = 'Adriaan de Groot' seat = 'Seat3' session-type = 'unspecified' session-class = 'user' session-state = 'online' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '/dev/ttyv0' remote-host-name = '' is-local = TRUE on-since = '2021-05-16T21:39:37.540427Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1001' VTNr = '1' switching to a text vt (ctrl-alt-F2) gives the same output from ck-list-sessions, and switching back to X (alt-F9) still has the same. I find the *display-device* line to be rather misleading: yes, I suppose root did start SDDM from there, but it's not where the session lives. Similarly, the VTNr is wrong (that .. seems familiar and may just be a SDDM bug) and x11-display-device isn't set at all. So it may be more a display manager / SDDM-specific problem, than CK itself.