ConsoleKit reports active/is-local only on the second+ login

2

Running KDE Frameworks 5, Plasma 5, using sddm as a display manager.

ConsoleKit and PAM-linux are both installed.

Upon login (using the sddm login screen), ck-list-sessions returns FALSE for both is-local and active. Only one session is present.

If I log out, then back in, the two fields are both TRUE, as expected.

sddm is not a console-kit supporting dm. Therefore, I am using the pam_ck_connector.so module to attach a consolekit session.

The sddm startup file (/usr/share/sddm/scripts/Xsession) is modified to launch using the line:

eval exec "ck-launch-session dbus-lauch --exit-with-session $session"

The (I think relevant) pam files are as follows:

/etc/pam.d/sddm:

auth            include         system-auth
account         include         system-account
password        include         system-password
session         include         system-session
session         optional        pam_loginuid.so
session         optional        pam_ck_connector.so nox11
session         optional        pam_warn.so

/etc/pam.d/sddm-greeter:

# Load environment from /etc/environment and ~/.pam_environment
auth            required pam_env.so

# Always let the greeter start without authentication
auth            required pam_permit.so

# No action required for account management
account         required pam_permit.so

# Can't change password
password        required pam_deny.so

# Setup session
session         required pam_unix.so
#session        optional pam_loginuid.so
session         optional pam_ck_connector.so
session         optional pam_warn.so

pam_warn.so lines have been added to force logging to the /var/log/auth.log file. A typical login looks something like:

<date/time> <pc-name> sddm-helper: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
<date/time> <pc-name> sddm-helper: pam_warn(sddm-greeter:session): function=[pam_sm_open_session] flags=0 service=[sddm-greeter] terminal=[:0] user=[sddm] ruser=[<unknown>] rhost=[<unknown>] 
<date/time> <pc-name> sddm-helper: pam_unix(sddm:session): session opened for user <user-name> by (uid=0)
<date/time> <pc-name> sddm-helper: pam_ck_connector(sddm:session): nox11 mode, ignoring PAM_TTY :0
<date/time> <pc-name> sddm-helper: pam_warn(sddm:session): function= [pam_sm_open_session] flags=0 service=  [sddm] terminal=[:0] user=[<user-name>] ruser=[<unknown>] rhost=[<unknown>] 
<date/time> <pc-name> polkitd[810]: Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session4 (system bus name :1.38 [/opt/kde/lib64/libexec/polkit-kde-authentication-agent-1], object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.ISO-8859-1)

How can I make my system start normally the first time?

chrisb2244

Posted 2015-06-09T04:27:45.063

Reputation: 307

The Xsession changes seem redundant with pam_ck_connector. Perhaps they're what breaks the login? The nox11 flag as well. – user1686 – 2015-06-09T05:30:02.257

So you suggest returning to eval exec "$session" and pam_ck_connector.so (without nox11)? – chrisb2244 – 2015-06-09T05:48:04.313

Making those changes, then logging out, switching to a text-based tty, then using init 3, followed by init 5, logging back in and running ck-list-sessions gives active = FALSE and is-local = TRUE. From here, running ck-launch-session ck-list-sessions returns two sessions (of course), the second of which (the newly spawned session) is TRUE/TRUE. This remains the case on logout/in (whereas previously went from FALSE/FALSE to TRUE/TRUE. Will reboot properly and test, but expect same results – chrisb2244 – 2015-06-09T06:08:00.973

Rebooting produces same results (as expected) – chrisb2244 – 2015-06-09T06:15:59.047

This gentoo forum page makes it look like the solution will require the ck-launch-session within Xsession, although also mentions removing the nox11 option. Will try that now

– chrisb2244 – 2015-06-09T06:21:13.793

Various changes only make this worse - the original setup seemed to produce the best results (at least on the second login). The first set of changes (as suggested by @grawity) produced something that looked promising, but didn't work out (as documented in 3rd comment) – chrisb2244 – 2015-06-09T07:07:28.263

I have this problem too and this has been the only place I have found a well-documented description of the problem. Initially I thought sddm was being started BEFORE all the other services so I moved it from S02sddm to S06sddm in the different rc.X folders in /etc. – Trann – 2015-06-18T17:52:36.403

No answers