Summary: | x11/slim r408067 breaks consolekit2 active session state | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Jesper Schmitz Mouridsen <jsm> | ||||
Component: | Individual Port(s) | Assignee: | Jesper Schmitz Mouridsen <jsm> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | arrowd, henry.hu.sh, samy.mahmoudi | ||||
Priority: | --- | Flags: | henry.hu.sh:
maintainer-feedback+
|
||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221452 | ||||||
Attachments: |
|
Description
Jesper Schmitz Mouridsen
2020-02-08 19:56:14 UTC
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 |