lightdm-1.7.7 does not create an active consolekit session

Reported by Andres-becerra on 2013-08-13
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Light Display Manager
High
Unassigned
Gentoo Linux
Fix Released
Medium

Bug Description

Apparently lightdm 1.7.5, 1.7.6, 1.7.7, 1.7.8, and 1.7.9 are not creating an active consolekit session.

This causes problems in distributions not using systemd: inability to mount disks or shutdown the system.

Some information in the following Gentoo bug report:
https://bugs.gentoo.org/show_bug.cgi?id=479660

Related branches

lp:~ian-abbott/lightdm/dont-clobber-session-tty
Merged into lp:lightdm at revision 1790
PS Jenkins bot: Approve (continuous-integration) on 2013-09-19
Robert Ancell: Approve on 2013-09-19

After upgrade to lightdm 1.7.7 I can't mount external disks or shutdown the system from the XFCE desktop.
As far as I could find out this is because lightdm doesn't create an active consolekit session therefore authentication for priviledged actions fails.

I went back to lightdm 1.4.0-r2 and the problem was gone.

Reproducible: Always

Steps to Reproduce:
1. upgrade to lightdm 1.7.7
2. restart lightdm
3. login and try to mount a USB disk or shutdown the system
Actual Results:
I get "not authorized" for the mount attempt.
The button for system shutdown is grey.

Expected Results:
mounted disk
coloured and working shutdown button

I've run a complete system upgrade (-uDN) when I came across this bug.
I reverted all changes in consolekit, pam, dbus and what else could have been involved config files:
emerge --noconfmem consolekit pambase shadow sys-fs/udisks sys-power/upower xfce-base/xfce4-session sys-auth/polkit gnome-extra/polkit-gnome udev xfce-base/xfdesktop
But that didn't help either.

Created attachment 355048
lightdm logfile for 1.4.0-r2

Created attachment 355050
lightdm logfile for 1.7.7

Download full text (5.1 KiB)

Portage 2.1.12.2 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.15-r3, 3.10.4-gentoo x86_64)
=================================================================
System uname: Linux-3.10.4-gentoo-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.2
KiB Mem: 8115404 total, 7217000 free
KiB Swap: 0 total, 0 free
Timestamp of tree: Sat, 03 Aug 2013 06:45:01 +0000
ld GNU ld (GNU Binutils) 2.23.1
app-shells/bash: 4.2_p45
dev-java/java-config: 2.1.12-r1
dev-lang/python: 2.7.5, 3.2.5-r1
dev-util/cmake: 2.8.10.2-r2
dev-util/pkgconfig: 0.28
sys-apps/baselayout: 2.2
sys-apps/openrc: 0.11.8
sys-apps/sandbox: 2.6-r1
sys-devel/autoconf: 2.13, 2.69
sys-devel/automake: 1.11.6, 1.12.6
sys-devel/binutils: 2.23.1
sys-devel/gcc: 4.6.3
sys-devel/gcc-config: 1.7.3
sys-devel/libtool: 2.4-r1
sys-devel/make: 3.82-r4
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
sys-libs/glibc: 2.15-r3
Repositories: gentoo x-portage
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=amdfam10"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -march=amdfam10"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="ftp://ftp.df.lth.se/pub/gentoo/ ftp://de-mirror.org/distro/gentoo/ ftp://mirror.mdfnet.se/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://trumpetti.atm.tut.fi/gentoo/ ftp://mirror.leaseweb.com/gentoo/ ftp://gentoo.tiscali.nl/pub/mirror/gentoo/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo "
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j6"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="3dnow 7zip X a52 aac acl acpi alsa amd64 apng audiofile berkdb bzip2 cairo cdda cddb cdio cdr cleartype cli consolekit cracklib crypt cups cxx dbus device-mapper dga dirac dri dts dvd dvdr encode exif ffmpeg flac fontconfig fortran gdbm gdu gnutls gtk hddtemp hwdb i18n iconv icq id3tag imap ipv6 jpeg jpeg2k kpathsea lame latex libass libnotify libsamplerate lm_sensors lzo mad matroska mjpeg mmx modules mp3 mpeg mudflap multilib musepack ncurses nls normalize nptl ogg opengl openmp pam pcre png policykit python readline sdl session sound speex sqlite sse ss...

Read more...

ck-list-sessions for version 1.7.7:
-----------------------------------
unix-user = '1000'
realname = '(null)'
seat = 'Seat1'
session-type = ''
active = FALSE
x11-display = ':0'
x11-display-device = ':0'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2013-08-03T18:32:01.232627Z'
login-session-id = '9'

ck-list-sessions for version 1.4.0-r2:
--------------------------------------
unix-user = '1000'
realname = '(null)'
seat = 'Seat1'
session-type = ''
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2013-08-03T19:03:32.001776Z'
login-session-id = '11'

I have the similar problems, but my desktop is KDE.
Using kdm as login manager solves all the problems.

In , Mads (mad3) wrote :

Same here. I think lightdm might require systemd-logind instead of ConsoleKit now...

(In reply to Mads from comment #6)
> Same here. I think lightdm might require systemd-logind instead of
> ConsoleKit now...

I know that lightdm got some support for systemd in version 1.7.0 (2 months ago) but I would be surprised if they immediately removed consolekit support.
Also I don't see a logind ebuild (it doesn't depend on systemd afaik) and the lightdm ebuild doesn't have a systemd dependency.

I have now done some regression testing and this bug was introduced with lightdm 1.7.5. Version 1.7.4 is the last one that works correctly (I also checked with the latest 1.7.9 and it is still there).
Running a diff over the 2 versions shows that there have been a lot of changes in the session handling code.

Probably worth taking it upstream then, 1.7.5 did come out with "This release contains a quite major refactoring so please look out for any regressions" after all

Yes please someone needs to take this upstream.

(In reply to Markos Chandras from comment #10)
> Yes please someone needs to take this upstream.

I have reported the issue upstream:

https://bugs.launchpad.net/lightdm/+bug/1211892

I could finally found a solution. I hope it works for you too.
Also, I don't use neither udev, eudev nor systemd and I don't use a conventional Gentoo environment. But it worth trying.

Packages used for the test,

x11-misc/lightdm-1.7.9::local USE="gtk introspection qt4 -kde (-razor)"
sys-auth/consolekit-0.4.6 USE="debug doc pam policykit -acl (-selinux) {-test}"

: lightdm since x11-misc/lightdm-1.7.9 needs a valid allocated tty to work on.
: most often /dev/tty7 is used for X.
: run consolekit daemon before lightdm otherwise dbus will run it on tty0 and
: will lock the tty7 until you manually kill consolekit daemon.

: /usr/sbin/console-kit-daemon --no-daemon --debug
: openvt -c 7 -- /usr/sbin/lightdm
: option -f isn't necessary in that case.
: verify if the panel has valid menus.
: open a user session in lightdm manager, run ck-list-sessions in the session
: 'display-device' should have /dev/tty7 as value this time.
:
: /usr/bin/ck-list-sessions
:
: Session2:
: unix-user = '1984'
: realname = 'User iGentoo'
: seat = 'Seat1'
: session-type = ''
: active = TRUE
: x11-display = ':0'
: x11-display-device = ':0'
: display-device = '/dev/tty7'
: remote-host-name = ''
: is-local = TRUE
: on-since = '2013-08-13T22:46:02.560669Z'
: login-session-id = '1'
: -----------------------------------------------------------------------------

In , Mads (mad3) wrote :

I tested starting /etc/init.d/consolekit before lightdm at version 1.7.7, and that didn't work... does this mean that there has been some fixing between 1.7.7 and 1.7.9, or does Jimmy.Jazz do something special that I haven't grasped yet?

(In reply to Mads from comment #13)
> I tested starting /etc/init.d/consolekit before lightdm at version 1.7.7,
> and that didn't work... does this mean that there has been some fixing
> between 1.7.7 and 1.7.9, or does Jimmy.Jazz do something special that I
> haven't grasped yet?

Do you mean you did:
root@bla # /etc/init.d/consolekit start
root@bla # openvt -c 7 -- /usr/sbin/lightdm

For me that works with 1.7.4, 1.7.7 and 1.7.9 (didn't try other versions).
Of course I had consolekit already running (so no need for the first command) and had to stop /etc/init.d/xdm before running the second.

(In reply to Jimmy.Jazz from comment #12)
> : lightdm since x11-misc/lightdm-1.7.9 needs a valid allocated tty to work
> on.
> : most often /dev/tty7 is used for X.

I have to admit that I have no idea how lightdm (or any other DM) knows which terminal to use. I guess tty7 has just established itself as a default that is used if nothing else is configured.

> : run consolekit daemon before lightdm otherwise dbus will run it on tty0 and
> : will lock the tty7 until you manually kill consolekit daemon.

Not sure I get that. I see the lightdm greeter on tty7 and the opened session is also there. There is a change in lightdm-1.7.5 that is supposed to allow greeter and session to run on different display servers. But from my perspective both run on the same just as usual for a simple desktop system. So it "forgets" to inform consolekit that the created session is running on tty7. Or it just puts in the wrong value.

x11-display = ':0'
x11-display-device = ':0' <--- This looks just like the x11-display and should be '/dev/tty7'

1.6.0 seems to be fixing the problem to me. I will bring this to portage for us who don't use systemd.

Changed in gentoo:
importance: Unknown → Medium

1.6.x also works for me, 1.7.x breaks ck session

Created attachment 358890
proposed patch

We're up to lightdm-1.7.15 now in gentoo, which still has the same bug, but this patch seems to fix it for me.

$ ck-list-sessions
Session6:
 unix-user = '1000'
 realname = 'Ian Abbott'
 seat = 'Seat1'
 session-type = ''
 active = TRUE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2013-09-17T18:09:45.380194Z'
 login-session-id = '4'

(In reply to Ian Abbott from comment #18)
> Created attachment 358890 [details, diff]
> proposed patch
>
> We're up to lightdm-1.7.15 now in gentoo, which still has the same bug, but
> this patch seems to fix it for me.
>
> $ ck-list-sessions
> Session6:
> unix-user = '1000'
> realname = 'Ian Abbott'
> seat = 'Seat1'
> session-type = ''
> active = TRUE
> x11-display = ':0'
> x11-display-device = '/dev/tty7'
> display-device = ''
> remote-host-name = ''
> is-local = TRUE
> on-since = '2013-09-17T18:09:45.380194Z'
> login-session-id = '4'

Thanks for the patch but it has to be accepted upstream first. I'd rather avoid carrying this patch in Gentoo forever.

For now, those that have this problem can use the 1.6.X ebuild?

Ian Abbott (ian-abbott) wrote :

This is the patch I submitted to the gentoo bug. It applies to lightdm-1.7.15.

The issue was that session_set_tty() was being set to the correct value "/dev/tty%d",vt by x_server_connect_session() if the vt value is valid, but then knobbled with an incorrect value later in the same function using the xdisplay value.

The patch removes the extra call to session_set_tty() that knobbles the tty value.

I guess it would be easy enough to apply to the trunk as it's just a one-line change.

(In reply to Markos Chandras from comment #19)
> Thanks for the patch but it has to be accepted upstream first. I'd rather
> avoid carrying this patch in Gentoo forever.
>
> For now, those that have this problem can use the 1.6.X ebuild?

I wonder how long it will take for upstream to apply the patch. So far they
haven't even confirmed that they have a bug. And I fear that they are so
focused on systemd that they won't even look at the bug report. :-(

So for now I'll stick to the 1.6.

Changed in lightdm:
status: New → Triaged
importance: Undecided → High

(In reply to Robert from comment #20)
> (In reply to Markos Chandras from comment #19)
> > Thanks for the patch but it has to be accepted upstream first. I'd rather
> > avoid carrying this patch in Gentoo forever.
>
> I wonder how long it will take for upstream to apply the patch. So far they
> haven't even confirmed that they have a bug. And I fear that they are so
> focused on systemd that they won't even look at the bug report. :-(

I've been doing my best to remedy that. At the moment it's looking good (Triaged, High)!

PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:lightdm at revision None, scheduled for release in lightdm, milestone Unknown

Changed in lightdm:
status: Triaged → Fix Committed
Changed in lightdm:
milestone: none → 1.7.16
status: Fix Committed → Fix Released

This is now fixed upstream in lightdm-1.7.16. (Though I haven't tested it yet, my one-line change has been committed.)

(In reply to Ian Abbott from comment #22)
> This is now fixed upstream in lightdm-1.7.16. (Though I haven't tested it
> yet, my one-line change has been committed.)

Wow that was fast!
I just gave 1.7.16 a try and it works. Now the 1.7.16 ebuild just needs to hit the tree to make it official.

Thanks for debugging it and getting upstream to take the fix.

x11-misc/lightdm-1.7.16 is now in the tree.

Awesome work. Thank you Ian for providing a fix and for pushing it upstream!

Changed in gentoo:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.