The fix of bug #206050 in ports r408067 breaks active session state for consolekit2 sessions, when using slim. Avoiding slim sets the session active as usual. e.g ck-launch-session /usr/local/bin/startlxqt in .xinitrc does not give an active session state using slim. If I delete the files/patch-const.h it works, but then but #206050 might be back.. This is on FBSD 12.1
Created attachment 211677 [details] Corrects the get_x11_device for FreeBSD This extra patch results in the following when using slim to login. #ck-list-sessions Session1: unix-user = '1001' realname = 'Jesper Schmitz Mouridsen' seat = 'Seat1' session-type = 'x11' session-class = 'user' session-state = 'active' active = TRUE x11-display = 'unix:0.0' x11-display-device = '/dev/ttyv8' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2020-02-15T19:52:20.005040Z' login-session-id = '' XDG_RUNTIME_DIR = '/var/run/user/1001' VTNr = '9' So with the patch slim works as expected with consolekit2 AFAICT
Comment on attachment 211677 [details] Corrects the get_x11_device for FreeBSD This patch looks good to me.
Comment on attachment 211677 [details] Corrects the get_x11_device for FreeBSD However, for some reason I can't change the maintainer-approval flag.
So, is this ready to be committed?
Hi all, I have tested attachment 211677 [details] yesterday and it seems ck-list-sessions only shows active status on the first session (mine is an Xfce session started with the SLiM autologin feature). If I log out and log in, ck-list-sessions shows inactive status. Could you confirm active status on subsequent logins?
Moreover, when I have an active status (first session), I can just switch to vt2 and switch back to vt9 to make it inactive. Could you also reproduce this behavior?
(In reply to Samy Mahmoudi from comment #6) I cannot replicate any of those problems,what does your .xinitrc looks like? Are you using the nvidia-driver with sc or intel and vt console?
Thank you for your tests and your reply Jesper. It will probably help me to troubleshoot what now happens to be a personal problem. > what does your .xinitrc looks like? #!/bin/sh # SLiM now starts Consolekit # Xfce now starts DBus # Temporary workaround # setxkbmap -model pc105 -layout fr,ru -option grp:alt_space_toggle,terminate:ctrl_alt_bksp DB="dbus-launch --exit-with-session" CK="ck-launch-session" case $1 in slim-autologin) # Requires patching SLiM, or SLiM autologin default to *) below ! # Lets me separate SLiM autologin from vt launch. exec startxfce4 ;; default) # SLiM default session (To set a system-wide default session, override "default" in slim.conf). exec startxfce4 ;; startxfce4) exec startxfce4 ;; mate-session) exec ${DB} mate-session ;; start-lumina-desktop) exec start-lumina-desktop ;; lxde) # https://forums.freebsd.org/threads/gdbus-error-org-freedesktop-consolekit-manager-generalerror.61540/ ${DB} startlxde exec startlxde ;; kodi-standalone) exec kodi-standalone ;; *) # exec ${CK} ${DB} openbox-session exec startxfce4 --with-ck-launch ;; esac > Are you using the nvidia-driver with sc or intel and vt console? I use intel and vt consoles.
(In reply to Samy Mahmoudi from comment #8) Can you try to skip the --with-ck-launch from "exec startxfce4 --with-ck-launch"
(In reply to Jesper Schmitz Mouridsen from comment #9) Skipping --with-ck-launch in my .xinitrc has no effect when using SLiM, as I have patched my SLiM so that in the case statement *) exec startxfce4 --with-ck-launch only gets executed from a console start. To follow you suggestion anyway, I decided to disable SLiM. After a reboot, startxfce4 (without --with-ck-launch) from console makes ck-list-sessions being silent, which is what I would expect. startxfce4 --with-ck-launch shows active status even after switches from vt ! If I log out, and relog in (from the same context: console + startxfce4 --with-ck-launch) active status is still there ! So your suggestion was definitely helpful, it revealed SLiM is probably the source of the problem (It's not really surprising as I have recently read somewhere that SLiM does not meet freedesktop.org standards relative to ConsoleKit; I can't remember where I have read that but there was said that SLiM is reusing ConsoleKit sessions where it should not do so). Do you use a display manager or start your desktop environment from the console?
> Do you use a display manager or start your desktop environment from the console? Please ignore that last question, I just confused this PR with another one where this question makes sense ;-)
I first managed to isolate the problem to slim_enable="YES" (onestarting SLiM after boot was OK whereas starting SLiM within the boot sequence was not). This led me examine the boot order, and after some time and effort I found a possible explanation: a sort of race condition between blacklistd and one of DBus/SLiM. Basically, I used to start blacklistd with the -r flag which was making blacklistd quite long to reload its database into a pf table at boot time (because I had accumulated more than 7000 IP addresses in my /var/db/blacklist.db). address/ma:port id nfail last access 37.49.226.62/32:22 OK 4/3 2020/06/12 16:06:30 46.37.82.113/32:22 0/3 1970/01/01 01:00:00 113.178.37.9/32:22 1/3 2020/06/12 14:10:19 218.149.178.64/32:22 0/3 1970/01/01 01:00:00 195.39.147.165/32:22 1/3 2020/06/12 15:06:15 175.112.17.42/32:22 0/3 1970/01/01 01:00:00 177.198.22.29/32:22 0/3 1970/01/01 01:00:00 197.39.66.5/32:22 1/3 2020/06/12 14:10:15 196.126.163.206/32:22 0/3 1970/01/01 01:00:00 192.168.0.35/32:22 0/3 1970/01/01 01:00:00 185.153.196.230/32:22 OK 4/3 2020/06/12 15:59:35 58.153.93.28/32:22 0/3 1970/01/01 01:00:00 For some reasons that remain unclear at the moment, the ConsoleKit daemon (launched by DBus as a service) was not behaving correctly, as if it had crashed during the boot because of blacklistd -r: Jun 12 07:40:20 dell7010 console-kit-daemon[1830]: DEBUG: VT_WAITACTIVE for vt 9 returned -1 Jun 12 07:40:20 dell7010 console-kit-daemon[1830]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device Jun 12 07:40:20 dell7010 console-kit-daemon[1830]: DEBUG: VT_WAITACTIVE for vt 1 returned -1 Jun 12 07:40:20 dell7010 console-kit-daemon[1830]: WARNING: Error waiting for native console 1 activation: Inappropriate ioctl for device Jun 12 07:40:20 dell7010 console-kit-daemon[1830]: DEBUG: VT_WAITACTIVE for vt 2 returned -1 Jun 12 07:40:20 dell7010 console-kit-daemon[1830]: WARNING: Error waiting for native console 2 activation: Inappropriate ioctl for device Jun 12 07:40:20 dell7010 console-kit-daemon[1830]: DEBUG: Active session changed: (null) Adding: # BEFORE dbus in /etc/rc.d/blacklistd seemed to solve my ConsoleKit problem (the idea was to force blacklistd -r to start before dbus (hence also before subbsequent ConsoleKit service launch and SLiM launch) but I am not sure that the previous change does what I want in a reliable way. After playing with blacklistd to remember my own choice of adding that -r flag, and a second thought, I chose to simply disable that -r flag which also seemed to solve my ConsoleKit problem. I might dive into this more thoroughly at some point, to identify the causes more precisely.
(In reply to Samy Mahmoudi from comment #12) examine ---> to examine
So thank you for your help. Let's wait for this to be committed !
A commit references this bug: Author: jsm Date: Mon Jun 22 14:56:36 UTC 2020 New revision: 539811 URL: https://svnweb.freebsd.org/changeset/ports/539811 Log: Corrects get_x11_device for FreeBSD fixes active session state for consolekit2 transfer maintainership PR: 243988 Approved by: henry.hu.sh@gmail.com (maintainer) Changes: head/x11/slim/Makefile head/x11/slim/files/patch-Ck.cpp