There are two sessions listed, one of which is active. I think this is OK for ACLs etc.

This is a product of how autologin works. i.e. it's not properly implemented. Compare it to e.g. how GDM autologin works. It implements all the pam logic correctly.

As stated on the list a while back I think this is OK for now (not ideal but acceptable) and should ultimately be replaced in the future by a full and proper pam implementation (i.e. we use gdm to do it as it implements things properly)

FWIW, a similar thing happens when you run startx from runlevel 3. It's slightly different as there is no logical and sensible way to "upgrade" a console session to an X11 one.

We should likely merge the consolekit patches from our xdm package into the autologin package.

CC: (none) => mageia

Silly question, but does this even matter?

What uses this consolekit information anyway (other than ACL handling stuff but that should work as one of the listed sessions is active and local so that should be OK.

I accept that it technically says it's not an X11 session, but like I say, does anything actually use that info?

Yes, udisks-glue, for example, can't register on the session.

Hmm, so udisks-glue uses consolekit? That's quite surprising, I'd have expected that to be disabled/removed seeing as consolekit is in it's death throes.

And anyway, I don't see anything in the udisks-glue code that specifically needs an X11 session for that to work...

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

I can certify this bug still exists on Mageia 2.
After manually creating an "/etc/sysconfig/autologin" file (to work around bug 3715), LXDM would autologin me into LXDE, but with an inactive session:

ck-list-sessions:
Session10:
	unix-user = '500'
	realname = 'Rubén Fernández Asensio'
	seat = 'Seat1'
	session-type = ''
	active = FALSE
	x11-display = ':0'
	x11-display-device = '/dev/tty1'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-07-24T11:10:08.025451Z'
	login-session-id = '1'
Session1:
	unix-user = '500'
	realname = 'Rubén Fernández Asensio'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-07-24T11:10:00.863794Z'
	login-session-id = '1'
	idle-since-hint = '2012-07-24T11:10:31.141227Z'

Without autologin, LXDM doesn't have this issue:

ck-list-sessions:
Session11:
	unix-user = '500'
	realname = 'Rubén Fernández Asensio'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/tty1'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-07-24T10:47:26.993776Z'
	login-session-id = '2'

I have tested with XDM and autologin logs into the same botched session. I didn't try with SLiM or LightDM but I would assume it's the same. On the other hand, autologin with GDM authenticates with ConsoleKit as required, although GDM has its own quirk: on logout, it leaves the 1rst virtual console empty and opens the 2nd one (is this related to bug 5051?):

ck-list-sessions:
Session5:
	unix-user = '500'
	realname = 'Rubén Fernández Asensio'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/tty2'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-07-24T13:24:00.836539Z'
	login-session-id = '5'

Colin, this is actually a serious bug, because without a properly activated session, a host of actions like rebooting, shutting down, or mounting a USB or DVD drive require the superuser password. This bug is causing a lot of trouble to users with lightweight desktop setups. Using KDM or GDM is not optimal on some systems. When is it going to be fixed?

CC: (none) => ruben33en-mandriva
Version: Cauldron => 2
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=3715

I also noticed the problems with lxdm and autologin.

A solution consists simply in using the autologin feature of lxdm instead of using the autologin package.

I had moreover made attentive with the bug 3715
But we did not listen to me

CC: (none) => paiiou

I have just made a new installation with Xfce and lightdm.
lightdm-1.0.11-1.mga2 do not work.

I install the packages of cauldron:
lightdm-1.4.0-6mga3, ligthdm-gtk-greeter-1.3.1-1mga3,
libligthdm-gobject1_0-1.4.0-6mga3, accountservice-0.6.25-2mga3

With these packages, the functioning is correct.

I modify the file /etc/lightdm/lightdm.conf to realize the autologin.

Autologin works.
The button logout button (power off) work too.

Actually, I believe a package update in bug #7593 will actually solve the original autologin issue. I need to finalise the validation here.

In addition to the above comment, the CK session will still remain "inactive" but because most policy related decisions will instead be based on the loginctl session it shouldn't actually matter. If you could test this fix (especially on mga2 i586) and comment on bug #7593 that would be most appreciated!

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD