New users fail when ~session is not part of show-indicators= in the config.

[Rene Herman]

At least with the gtk2-greeter, if ~session is not part of the "show-indicators=" setting in /etc/lightdm/lightdm-gtk-greeter.conf then newly added users get a garbage value for "Xsession=" in /var/lib/AcountsSerive/users/<username> and fail to log in as a result. I suppose some string-pointer goes unitiaized in that case, and the "Xsession=" value just ends up being some random memory dump.

[Rene Herman (rene.herman)]

Typo: /var/lib/AccountsService/users/<username>.

[Rene Herman (rene.herman)]

Patch both confirmed and unconfirmed. That is, confirmed that with in /etc/lightdm/lightdm-gtk-greeter.conf:

  show-indicators=~power

and after "useradd -m -g users newlyaddeduser && passwd -d newlyaddeduser", login "newlyaddeduser" in through lightdm now results in a better looking /var/lib/AccountsService/users/newlyaddeduser:

  [User]
  XSession=default
  SystemAccount=false

whereas the XSession value used to the mentioned garrbage value.

Unconfirmed in the sense that "newlyaddeduser" still actually fails to log in, supposedly since there no such thing as a "default" XSession on my system: there's only a "mate.desktop" in my /usr/share/xsessions and the users that login correctly have Xsession=mate there. This sounds like a seperate issue -- but on the other hand, if I *do* add "~session" to the indicators, "newlyaddeduser" is correcyly assigned this only one session-type. As such, "default" might still need to be something else?

[Andrew P. (kalgasnik)]

There is one condition to see this bug: user must have invalid session settings.
You can set "Xsession" key to invalid value in /var/lib/AccountsService/users/<username> file.
Or you can delete this file, greeter will use value provided by lightdm_greeter_get_default_session_hint(). This value can be invalid in some dists (in Arch it is "default" - there is no real session with name "default").

What dist are you using? 51% it is not Ubuntu.

Provided branch must fix this bug.

[Rene Herman (rene.herman)]

Arch indeed. Just browsed around a bit to try and see if there would be an agreed-upon Arch way to set a default session type (i.e., symlinking /usr/share/xsessions/default to some actually present /usr/share/xessions/session.desktop file, supposedly) but as far as I can see, it is not expected that one should need to do this.

It's also fixed by setting f.e. user-session=mate in /etc/lightdm/lightdm.conf:SeatDefaults. Should I go edit some Arch Wiki page to recommend such or will this indeed be fixed/worked-around lightdm-side? It seems the consistent way to handle this (in the gtk2-greeter at least; don't know if the other greeters show the same behavior) would be to mimic the logic of when the ~session indicator is shown, whether or not it in fact is...

[Rene Herman (rene.herman)]

Second patch (set_session_check) also tested -- slight snag it seems.

Setup: commented "user-session=mate" in lightdm.conf again (ie, so that it is "default" again) and restarted lightdm:

If I now try to log in "newlyaddeduser2" -- with the "2" signifying that it's a really new user without a previous session and not the one from above -- I still get the same behavior as before the first time after adding the user: /var/lib/AccountsService/users/newlyaddeduser2 with "XSession=default" and hence a login failure. If I however then simply try it again -- it works, and the AccountService file is updated with "XSession=mate", the only session in /usr/share/xsessions/ on my system.

[Andrew P. (kalgasnik)]

Can you please test it now?

[Rene Herman (rene.herman)]

Confirmed: at revision 277, things work as expected for me. That is -- newly added users succesfully login to the only session that is available on my system (and do so without me explicitly specifying said session as a SeatDefault).

[Sean Davis (bluesabre)]

This has been fixed in Utopic, and a fixed package is now available in trusty-proposed. Please help with SRU verification.

https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871

Run the test case, and comment if successful. Please see https://wiki.ubuntu.com/QATeam/PerformingSRUVerification for more information.

[Rene Herman (rene.herman)]

I believe I'm the only one guaranteed to be sent that last comment via email, so assuming that's specifically to me: not an Ubuntu user, I'm afraid.

In fact, also no longer an arch user and although probably temporary, in double fact at the moment not even a Linux user; after 15 years of exclusive Linux use, systemd and its accompanying at every update shifting but ever vast array of dependency loops and races in the arch linux bootup has managed to finally drive me out.

For now I will admit; Windows is perhaps almost equally annoying. But Ubuntu: save yourself and Linux while you're at it: do NOT adopt that race-ridden-by-design computer-science student pipedream after all.

Not unless you simultaneously decide to become RedHat, which has a number of years ago in turn decided to try and become Microsoft and/or Apple in denying users as much freedom to control/define their own systems as possible. Note that doing so will not get you Windows users: it works the other way around. Don't go by a mere month of testing either -- at first, I liked it as well...

Now THAT was a misdirected rant if ever I saw one. Still, after 15 years one is tempted to try and help save what little is left of the Linux desktop SOMEwhere...