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.
Sorry for the long delay - I've got "sidetracked" by day job issues. I've installed FreeBSD 13 in the meantime (13.0-RELEASE-p3 right now) and just noticed that the problem is no longer present. Based on the somwehat recent activity on this bug, it seems there are still users on FreeBSD 12.x with this issue, though.
(In reply to Christina Mueller from comment #25) > 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 managed to reproduce this on FreeBSD 13 with SDDM, so the problem is still there. However, ck-list-sessions output is a little different now: x11-display-device: '/dev/ttyv8' display-device: '/dev/ttyv0' Both these values don't seem right to me. X starts on ttyv9, and ttyv0 isn't any special. I'll try diggin into ConsoleKit itself.
(In reply to Gleb Popov from comment #36) Hi Some years ago I tried to solve the x-display device thing, and I think it worked well back then.. Since Linux and FreeBSD differ in tty values of processes: Linux ps gives the actual tty of Xorg IIRC, FreeBSD does not. So in FreeBSD the get_x11_device in consolekit is obtained effectively by sudo fstat /dev/ttyv* Adgangskode: USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root Xorg 1652 13 /dev 93 crw------- ttyv8 rw /dev/ttyv8 Is not vtnr9 == ttvy8 I do not recall if Console kit counts from zero, I do not think so. But the above X is started with vt09 which is apparently ttyv8 if I am not mistaken. So TL;DR I do not think it is a CK issue. Can you check if slim works? or ck-launch-session startDEOFCHOICE, just narrow down the issue...
(In reply to Jesper Schmitz Mouridsen from comment #37) Yep, I managed to reproduce this with startx & ck-launch-session. Just like Christina noted, there is something special about ttyv0 and the bug doesn't manifest when this ttyv is used. To reproduce, after a clean boot, I logged in on ttyv2, ran startx and launched KDE Plasma. ck-list-sessions reported active = TRUE Then I switched to ttyv3, then back to ttyv9 into the X and now ck-list-sessions reports active = FALSE It is hard to catch this bug because usually ttyv0 is used to log in to run startx, and the bug doesn't manifest itself when ttyv0 is open.
Created attachment 229140 [details] Use /dev/console instead of /dev/ttyv0 With this patch I could not reproduce the issue
(In reply to Jesper Schmitz Mouridsen from comment #39) I can confirm that this fixes the issue for me too! It is actually a bit funny, because when I started debugging this, I saw that the port pulls in patches from the GitHub repo, but didn't check every patch. I was thinking that this change is also present in our port of consolekit. Was it simply overlooked or is there some reason to not commit it into the ports tree?
Great. Well the extrapatches came from https://github.com/freebsd/freebsd-ports/commit/7c53ae6055f1b03148dfda5acf2540bbd1af5029 which is about wayland support. So somone should test if it patch 18a058576d118dec428d81c7e2e3369d9ec939d0.patch really is needed, i.e needed for wayland
I tested the patch with ck-launch-session sway. It works as expected.
(In reply to Jesper Schmitz Mouridsen from comment #42) Should I commit this to the Ports, then?
Yes, why not. Thanks
(In reply to Jesper Schmitz Mouridsen from comment #44) Oh I read your patch wrongly -_\ You actually removing one of commits. I'll ping Greg first on this matter.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=bc31b1a620cadcdb5fa688de58d2fa04edccdc18 commit bc31b1a620cadcdb5fa688de58d2fa04edccdc18 Author: Jesper Schmitz Mouridsen <jsm@FreeBSD.org> AuthorDate: 2021-11-04 15:45:20 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2021-11-09 16:08:33 +0000 sysutils/consolekit2: Remove problematic patch. This change prevents ConsoleKit from tracking a currently active terminal. PR: 221452 Reviewed by: Greg V <greg@unrelenting.technology> sysutils/consolekit2/Makefile | 2 +- sysutils/consolekit2/distinfo | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-)
The problem should be fixed now, thanks everyone involved.
Do you plan to merge into 2021Q4 branch for /quarterly packages? Assuming ports 7c53ae6055f1 introduced the regression fixed here the following branches are affected: $ git branch -r --contains 7c53ae6055f1 [...] origin/2021Q2 origin/2021Q3 origin/2021Q4 [...]
A commit in branch 2021Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3a17aaa55efe7905f5dc1ec6837450bf8dc5c17d commit 3a17aaa55efe7905f5dc1ec6837450bf8dc5c17d Author: Jesper Schmitz Mouridsen <jsm@FreeBSD.org> AuthorDate: 2021-11-04 15:45:20 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2021-11-12 16:39:41 +0000 sysutils/consolekit2: Remove problematic patch. This change prevents ConsoleKit from tracking a currently active terminal. PR: 221452 Reviewed by: Greg V <greg@unrelenting.technology> (cherry picked from commit bc31b1a620cadcdb5fa688de58d2fa04edccdc18) sysutils/consolekit2/Makefile | 2 +- sysutils/consolekit2/distinfo | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-)
13.1-RC1 consolekit2 latest pkg sddm X11plasma5 login after reboot terminal in plasma or new virtual terminal text login have same output # ck-list-sessions Session2: unix-user = '1001' realname = 'me' seat = 'Seat3' session-type = 'unspecified' session-class = 'user' session-state = 'online' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '/dev/ ? ' remote-host-name = '' is-local = TRUE on-since = '2022-04-06T18:35:13.258090Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1001'
Switched users. Seat 5 created on virtual terminal 11. ck debug /var/log/messages: 7 Apr 2022 05:17:49 hpz2freebsd devd[97897] check_clients: dropping disconnected client 7 Apr 2022 05:17:56 hpz2freebsd dbus-daemon[22255] [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.109" (uid=1002 pid=54674 comm="") interface="org.freedesktop.ConsoleKit.Manager" member="CanSuspendThenHibernate" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid=0 pid=50007 comm="") 7 Apr 2022 05:17:56 hpz2freebsd pulseaudio[60573] [(null)] oss-util.c: '/dev/dsp0' doesn't support full duplex 7 Apr 2022 05:17:56 hpz2freebsd pulseaudio[60573] [(null)] oss-util.c: '/dev/dsp1' doesn't support full duplex 7 Apr 2022 05:17:56 hpz2freebsd pulseaudio[60573] [(null)] oss-util.c: '/dev/dsp2' doesn't support full duplex 7 Apr 2022 05:17:56 hpz2freebsd pulseaudio[60573] [(null)] oss-util.c: '/dev/dsp3' doesn't support full duplex 7 Apr 2022 05:17:56 hpz2freebsd pulseaudio[60573] [(null)] oss-util.c: '/dev/dsp5' doesn't support full duplex 7 Apr 2022 05:17:56 hpz2freebsd pulseaudio[60573] [(null)] oss-util.c: '/dev/dsp6' doesn't support full duplex 7 Apr 2022 05:17:56 hpz2freebsd /hp-systray[61884] hp-systray[61884]: error: option -s not recognized 7 Apr 2022 05:18:10 hpz2freebsd devd[97897] check_clients: dropping disconnected client 7 Apr 2022 05:18:11 hpz2freebsd kernel pid 76521 (kcminit), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:18:11 hpz2freebsd kernel pid 76827 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:18:11 hpz2freebsd kernel pid 76877 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:18:11 hpz2freebsd kernel pid 77216 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:18:11 hpz2freebsd kernel pid 77453 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:20:10 hpz2freebsd devd[97897] check_clients: dropping disconnected client 7 Apr 2022 05:20:32 hpz2freebsd kernel pid 79961 (kcminit), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:20:32 hpz2freebsd kernel pid 80084 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:20:32 hpz2freebsd kernel pid 80186 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:20:37 hpz2freebsd devd[97897] check_clients: dropping disconnected client 7 Apr 2022 05:20:53 hpz2freebsd syslogd last message repeated 1 times 7 Apr 2022 05:20:54 hpz2freebsd kernel pid 82164 (kcminit), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:21:33 hpz2freebsd kernel pid 82276 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:21:33 hpz2freebsd kernel pid 82277 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:21:33 hpz2freebsd kernel pid 82503 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped) 7 Apr 2022 05:21:33 hpz2freebsd kernel pid 82632 (baloo_file_extracto), jid 0, uid 1001: exited on signal 6 (core dumped)
(In reply to Bluey from comment #50) The "Session2" and "Seat3" looks strange. Can you provide exact steps to reproduce this?
Exact steps presently: boot machine sddm login plasma5/X11 open terminal # ck-list-sessions How I got here: new machine about 2 wks ago HP Z2 MINI G5 Xeon installed FreeBSD 13.0-RELEASE USB img installed X problems booting and talking to graphics hardware installed FreeBSD 13.1-BETA03 USB img installed Gnome, Cinnamon, Linuxulator/Brave/Netflix upgraded to 13.1-RC1 installed KDE plasma5 testing fast user switching (possibly messed something using sudo instead of su along the way) Chatting with grahamperrin who seems in same boat. https://forums.freebsd.org/threads/consolekit-sddm-switch-user.84693/
made a new user. reboot machine. login. run terminal. $ ck-list-sessions Session2: unix-user = '1004' realname = 'User Test0' seat = 'Seat3' session-type = 'unspecified' session-class = 'user' session-state = 'online' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '/dev/ ? ' remote-host-name = '' is-local = TRUE on-since = '2022-04-07T21:35:09.605578Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1004'
Looks like the problem might be with sddm, since the sddm user processes are MIA. https://www.freebsd.org/cgi/man.cgi?query=sddm&sektion=1&manpath=freebsd-release-ports sddm runs the greeter as a system user named sddm whose home directory needs to be set to /var/lib/sddm. If pam and systemd are available, the greeter will go through logind, which will give it access to drm devices. sddm user exists. [CODE]# cat/etc/passwd [...] sddm:*:219:219:SDDM Display Manager user:/var/lib/sddm:/usr/sbin/nologin [...][/CODE] processes run by sddm user do not. [CODE]# ps -auxw -U sddm USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND # [/CODE]
Is it OK if root runs sddm???? [CODE]# ps -auxwd [...] root 79043 0.0 0.1 72672 17108 v0- I 07:34 0:00.02 |-- /usr/local/bin/sddm root 3885 2.1 0.3 25338840 111728 - S 07:37 3:38.36 | |-- /usr/local/bin/Xorg -nolisten tcp -auth /var/run/sddm/{8356a505-04c2-496f-98e3-1d5ef26bdef root 6253 0.0 0.2 68384 51284 - I 07:38 0:00.01 | `-- /usr/local/libexec/sddm-helper --socket /tmp/sddm-auth45f23e07-4eaf-49ed-b6c3-bc55691129e5 me 6430 0.0 0.0 16924 4892 - I 07:38 0:00.00 | `-- ck-launch-session startplasma-x11 me 7216 0.0 0.2 86492 61480 - I 07:38 0:00.03 | `-- startplasma-x11 [...][/CODE] Is console-kit-daemon meant to be running as a daemon or not??? [CODE]root 80648 0.0 0.0 90436 9708 - I 07:34 0:00.10 |-- /usr/local/sbin/console-kit-daemon --no-daemon [/CODE]
looks better now. Can mod delete all my unnecessary messages? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228116 scrubbed out ~.xsessions and ~.xinitrc and security.bsd.see_other*=0 in /etc/sysctl.conf $ ck-list-sessions Session2: unix-user = '1001' realname = 'me' seat = 'Seat1' session-type = 'unspecified' session-class = 'user' session-state = 'active' active = TRUE x11-display = ':0' x11-display-device = '/dev/ttyv8' display-device = '/dev/ ? ' remote-host-name = '' is-local = TRUE on-since = '2022-04-08T21:35:00.606683Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1001' VTNr = '9'
Currently suspect the bugs are in sddm calling ck. Think I found one. https://github.com/sddm/sddm/issues/1540 Suspect errors in sddm state handling. Still looking.
13.1-RC2 "active = FALSE" still has bugs. Login and switch users creates a new session all of which are tagged not active. Still trying to figure if sddm or ck is the problem. Leaning towards sddm but OP had problem with lightdm. # ck-list-sessions Session6: unix-user = '1001' realname = 'me' seat = 'Seat1' session-type = 'unspecified' session-class = 'user' session-state = 'online' active = FALSE x11-display = ':2' x11-display-device = '/dev/ttyva' display-device = '/dev/ ? ' remote-host-name = '' is-local = TRUE on-since = '2022-04-13T20:04:13.959578Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1001' VTNr = '11' Session10: unix-user = '1001' realname = 'me' seat = 'Seat1' session-type = 'unspecified' session-class = 'user' session-state = 'online' active = FALSE x11-display = ':1' x11-display-device = '/dev/ttyva' display-device = '/dev/ ? ' remote-host-name = '' is-local = TRUE on-since = '2022-04-13T20:13:06.751603Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1001' VTNr = '11' Session2: unix-user = '1001' realname = 'me' 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 = '2022-04-13T20:01:19.104886Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1001' VTNr = '9'
> Leaning towards sddm but OP had problem with lightdm./christina I haven't had the problem ever since FreeBSD 13. I'm still using lightdm but have switched from the old character-mode console (kern.vty=sc, BIOS boot) to EFI and kern.vty=vt. The result of this change was not only that ACPI S3 suspend/resume finally started working but also allowed switching back and forth between X11 and character VCs without video corruption (I'm using the nvidia driver in case this makes any difference). Either way, ck-list-sessions is correctly reporting the active/inactive state of the X11 session at this point.
Still on 13.1-RC2. Just tried lightdm. Similar problem but worse. Switch users after 2 goes straight to root console. Going back to trying to debug sddm and ck.
"Switched users" - 4 logged in, 1,2,4 the same test user and 3 as me. Logging out of #4 to get back to #3 seems to reliably nuke the entire ck database. ck-list-sessions returns nothing.
Created attachment 236101 [details] parse number from devname differently.. This should fix user switching with lightdm, and retain the correct session active. Works for me, please test.
(In reply to Jesper Schmitz Mouridsen from comment #63) This will not parse /dev/ttyva correctly.
(In reply to Gleb Popov from comment #64) Perfectly correct, but ttyva is for me on 13.1 always set to ttyv10, i.e the device number is in decimal format. I tried another approach where ck-get-x11-device returned /dev/ttyva so that the vt number would be correct, but that did not work.
(In reply to Jesper Schmitz Mouridsen from comment #65) Well using ck-launch-session gives ttyva lightdm does give ttyv10. I will dig into that..
Created attachment 236106 [details] patch for lightdm This sets the x11-display-device to the format expected by consolekit. (hex not decimal for the number part) when using ligthdm.
(In reply to Jesper Schmitz Mouridsen from comment #67) As far as I know, it is not a hexadecimal number. It can go up to v. https://github.com/swaywm/wlroots/pull/1945
(In reply to Jesper Schmitz Mouridsen from comment #67) I tried both patches if I switch users, I can get back to any of them.
(In reply to Bluey from comment #61) What hardware are you using? Does the following patch help https://gist.github.com/jsm222/1de28f4e45cf6435e0061e9b3654cf6b the patch simply ensures avoiding use of /dev/tty.
(In reply to Jesper Schmitz Mouridsen from comment #70) Sorry, I tried the patch and forgot to reply, and I tried back today. It is the same result. The MATE desktop is stuck in tty 8 with the screen lock, and the lightdm is tty 9. When trying to log back in, it goes to a black screen and back to lightdm. With or without the patch, it does that. I tried with XFCE, and it did the same thing then MATE. Since XFCE was on tty 8 without a screen look. This represents a security issue. Seems like switching users with consolekit2, is not safe. I will make a proper ticket later.
I made user switch to work with SDDM by implementing a lot of login1 interfaces on the ConsoleKit side. This work is going to land soon and may also fix LightDM too.
(In reply to Gleb Popov from comment #72) Cool, I will keep looking until it gets in. Thanks for letting me know and for your work on Consolekit.
This bug is closed, but I'm seeing this exact behavior still on sysutils/consolekit2:1.2.6_3 A similar problem is just being fixed in lightdm in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277114 where it was found that vt devs are created with base32 suffixes - eg /ttyv[0-9a-v]+/ But even while testing that patch on my system, this one persists. This smells like an off-by-one error somewhere in how we're counting ttys