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: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: Jesper Schmitz Mouridsen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-12 19:19 UTC by Christina Mueller
Modified: 2024-02-23 08:04 UTC (History)
14 users (show)

See Also:
jbeich: merge-quarterly?


Attachments
Use /dev/console instead of /dev/ttyv0 (1.83 KB, patch)
2021-10-30 11:23 UTC, Jesper Schmitz Mouridsen
no flags Details | Diff
parse number from devname differently.. (808 bytes, text/plain)
2022-08-24 23:12 UTC, Jesper Schmitz Mouridsen
no flags Details
patch for lightdm (927 bytes, patch)
2022-08-25 09:35 UTC, Jesper Schmitz Mouridsen
no flags Details | Diff

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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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?
Comment 31 Eric Turgeon freebsd_committer freebsd_triage 2020-11-03 13:13:52 UTC
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
Comment 32 Gleb Popov freebsd_committer freebsd_triage 2020-11-05 10:30:35 UTC
(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.
Comment 33 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2020-11-11 16:06:15 UTC
FWIW I cannot reproduce the issue with ssdm 18.1_4 on 12.1
Comment 34 Adriaan de Groot freebsd_committer freebsd_triage 2021-05-16 21:42:35 UTC
- 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.
Comment 35 Christina Mueller 2021-09-26 19:30:05 UTC
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.
Comment 36 Gleb Popov freebsd_committer freebsd_triage 2021-10-21 11:47:07 UTC
(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.
Comment 37 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2021-10-29 16:10:33 UTC
(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...
Comment 38 Gleb Popov freebsd_committer freebsd_triage 2021-10-30 07:34:34 UTC
(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.
Comment 39 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2021-10-30 11:23:23 UTC
Created attachment 229140 [details]
Use /dev/console instead of /dev/ttyv0

With this patch I could not reproduce the issue
Comment 40 Gleb Popov freebsd_committer freebsd_triage 2021-10-30 13:23:24 UTC
(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?
Comment 41 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2021-10-30 13:45:57 UTC
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
Comment 42 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2021-10-31 17:44:45 UTC
I tested the patch with ck-launch-session sway. It works as expected.
Comment 43 Gleb Popov freebsd_committer freebsd_triage 2021-11-02 15:31:13 UTC
(In reply to Jesper Schmitz Mouridsen from comment #42)
Should I commit this to the Ports, then?
Comment 44 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2021-11-02 16:51:52 UTC
Yes, why not.

Thanks
Comment 45 Gleb Popov freebsd_committer freebsd_triage 2021-11-02 16:54:53 UTC
(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.
Comment 46 commit-hook freebsd_committer freebsd_triage 2021-11-09 16:09:48 UTC
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(-)
Comment 47 Gleb Popov freebsd_committer freebsd_triage 2021-11-09 16:12:25 UTC
The problem should be fixed now, thanks everyone involved.
Comment 48 Jan Beich freebsd_committer freebsd_triage 2021-11-10 21:09:55 UTC
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
[...]
Comment 49 commit-hook freebsd_committer freebsd_triage 2021-11-12 16:41:01 UTC
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(-)
Comment 50 Bluey 2022-04-06 18:50:37 UTC
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'
Comment 51 Bluey 2022-04-06 19:26:25 UTC
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)
Comment 52 Gleb Popov freebsd_committer freebsd_triage 2022-04-07 08:56:42 UTC
(In reply to Bluey from comment #50)
The "Session2" and "Seat3" looks strange. Can you provide exact steps to reproduce this?
Comment 53 Bluey 2022-04-07 11:37:56 UTC
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/
Comment 54 Bluey 2022-04-07 21:41:21 UTC
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'
Comment 55 Bluey 2022-04-08 19:54:41 UTC
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]
Comment 56 Bluey 2022-04-08 20:30:52 UTC
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]
Comment 57 Bluey 2022-04-08 21:40:33 UTC
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'
Comment 58 Bluey 2022-04-14 22:01:14 UTC
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.
Comment 59 Bluey 2022-04-15 19:03:08 UTC
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'
Comment 60 Christina Mueller 2022-04-16 00:04:19 UTC
> 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.
Comment 61 Bluey 2022-05-04 20:18:44 UTC
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.
Comment 62 Bluey 2022-05-04 20:25:15 UTC
"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.
Comment 63 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2022-08-24 23:12:28 UTC
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.
Comment 64 Gleb Popov freebsd_committer freebsd_triage 2022-08-25 07:46:01 UTC
(In reply to Jesper Schmitz Mouridsen from comment #63)
This will not parse /dev/ttyva correctly.
Comment 65 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2022-08-25 08:03:03 UTC
(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.
Comment 66 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2022-08-25 08:18:30 UTC
(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..
Comment 67 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2022-08-25 09:35:16 UTC
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.
Comment 68 Ting-Wei Lan 2022-08-27 16:19:59 UTC
(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
Comment 69 Eric Turgeon freebsd_committer freebsd_triage 2022-08-27 17:20:26 UTC
(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.
Comment 70 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2022-08-28 18:04:27 UTC
(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.
Comment 71 Eric Turgeon freebsd_committer freebsd_triage 2023-09-07 10:41:36 UTC
(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.
Comment 72 Gleb Popov freebsd_committer freebsd_triage 2023-09-07 12:08:14 UTC
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.
Comment 73 Eric Turgeon freebsd_committer freebsd_triage 2023-09-07 21:57:02 UTC
(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.
Comment 74 Dan Kotowski 2024-02-23 08:04:24 UTC
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