Replace ~/.dmrc with AccountsService

Robert, Michael do you know if anything is blocking that?

seems like bug #818201 could be a side effect as well (.dmrc not readable from the greeter leading to the session not being correctly set).

Looks good, I hadn't noticed that accounts service provided this. Note that GDM doesn't appear to use this currently in git master. Also this will probably break migrations? Needs to be investigated.

This bug was fixed in the package lightdm - 0.9.3-0ubuntu6

---------------
lightdm (0.9.3-0ubuntu6) oneiric; urgency=low

  * Backport r1065 to use account service instead of .dmrc (lp: #823718),
    should fix the session not being correct remembered (lp: #818201)
 -- Sebastien Bacher <email address hidden> Tue, 23 Aug 2011 16:21:59 +0200

Is it supposed to work for auto-login too? Because it doesn't work for me: the Unity is always started while the last session I manually chose was the gnome-shell session.

Julien, it should. Please open a new bug if it isn't.

@Robert Ancell
I reported bug #834515 about this issue.

Just a little provoking question? What is actually the point of AccountsService?

The fact that AccountsService stores the default session and language for a user *locally* in /var/lib/AccountsService/users/$USER is actually a very bad idea. There is a reasoning behind .dmrc being stored in the home directory which is to be independent of the login machine.

Imagine the scenario of a big university department with hundreds of students and a computer pool. These students continuously switch computers and AccountsService is actually a hindrance in this case. Whenever a student hops to a different machine, they have to set their default session and language again. What's even worse, since they don't know which machines they have used, it might be necessary to set their defaults again or it might be not.

So, to conclude, switching from .dmrc to AccountsService has actually reduced the flexibility of lightdm with no apparent gain in functionality (unless I miss something).

It should be configurable in the lightdm configuration whether AccountsService or .dmrc are used (since we depend on this feature). I'm going to file a bug report on this and if the lightdm developers decide not to fix it anytime soon, I'm going to jump to fix it myself :).

Cheers,

Adrian

@John: please don't comment on closed bugs, the bug tracker is not a forum or developer list

> So, to conclude, switching from .dmrc to AccountsService has actually reduced the flexibility of lightdm with no apparent gain in functionality (unless I miss something).

The reasons of using account service include:
- the fact that it has proper apis to use rather than having to deal with a not-well-documented keysfile
- the fact that GNOME standardized on using it (e.g gnome-control-center's users administration tools is using it, gdm is using it)
- it seems a better freedesktop standard way to do thing

That said accountsservice does has issue and we should work with upstream on fixing those, feel free to open bugs on https://bugs.freedesktop.org/enter_bug.cgi?product=accountsservice

@John
I think you did miss a few things.

Did you check how this bug was resolved? accountsservice (a-s) stores the last entered session type in both a-s and ~/.dmrc. As regards language, a-s stores languages and locales settings in both a-s and ~/.pam_environment. If you mount e.g. a USB with HOME, and ~/.dmrc and a-s respective ~/.pam_environment and a-s are out of sync, I think the current session and language are grabbed from a-s, so your students should know, after all.

So, to conclude, I'm not sure what it is you would write in that bug report.

> So, to conclude, I'm not sure what it is you would write in that bug report.

Just as a heads up: Restoring session still does not work in lightdm. And, as for all arguments that speak for accounts-service-daemon, the fact remains that switching from .dmrc to a-s-d broke session save and restore for many corporate users.

It's super easy to reproduce if you have two computers on a network with a shared home directory:

- user A logs in to machine "host001", chooses MATE and en_US.UTF-8 as their defaults
- user A logs out
- user A logs into machine "host002" and neither MATE or en_US.UTF-8 are restored as settings but some random settings which depend on who previously logged into the machine and what user A's settings were last time logging in to "host002"

All of this worked fine previously when using ~/.dmrc and is still broken after switching to a-s-d. This really needs to be fixed and if the concept of a-s-d is supposed to be kept, then a-s-d should be able to store it's database settings across different host with the same shared home directory.

Adrian

@Adrian: As Sebastien said more than two years ago, please don't use this closed bug report for discussion. If you want to discuss the overall design of the login infrastructure, please post to a mailing list, e.g. ubuntu-desktop or ubuntu-devel-discuss. If you have specific suggestions to improvements, please file a new bug report.

Well, the thing is: This change broke session management and therefore I think it's fair to comment on this right here.

Serious question: Are you actually using lightdm yourself? I mean, it's obviously completely broken. It doesn't even restore the settings on the same machine these days anymore.

I have filed another bug report (#1069494) on this and I don't understand why you ask me to discuss this on an ubuntu mailing list. This is an upstream *bug* and therefore this belongs to the upstream bug tracker.

We have the same problem in Debian as well, so it's not an issue of what distribution is used.

Adrian

Fair or not, this bug report is closed, and further comments won't get the attention you want.

Please keep the discussion on bug #1069494. But what you want to achieve would probably affect several packages, and I think you should use a mailing list to check out what others think about the overall idea.