Launchpad has imported 45 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=617465.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2010-07-23T07:04:08+00:00 Karel wrote: Description of problem: GDM ignores user's default session, it is always set to GNOME no matter what content is stored ~/.dmrc. Version-Release number of selected component (if applicable): gdm-2.30.2-1.fc13.x86_64.rpm, How reproducible: Always. Steps to Reproduce: 1. Install other windows manager (I tried with xmonad and awesome), or simply create *.session representing raw X session. 2. Login to the newly created session using GDM 3. Log out Actual results: After logging out from Awesome the Awesome session should be selected as default, but GNOME is selected as default session although the Awesome is shown as default session in ~/.dmrc. Expected results: After logging out from Awesome window manager is selected as user's default session. Additional info: This works on Fedora 12, with gdm-2.28.2.3.fc12, so it must be a regression. I'm using custom gnome-session configuration which launches special Gnome session where Awesome replaces panel and window manager, however the issue occurs even if Awesome is run in the standalone mode or an raw Xsession is launched. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/0 ------------------------------------------------------------------------ On 2010-08-02T10:00:17+00:00 Tajidin wrote: This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/1 ------------------------------------------------------------------------ On 2010-11-04T19:23:18+00:00 Andrew wrote: I have run across this problem, too, on Fedora 14. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/2 ------------------------------------------------------------------------ On 2011-05-02T21:37:47+00:00 Andrew wrote: I have confirmed that this is still a problem in Fedora 15. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/3 ------------------------------------------------------------------------ On 2011-05-02T21:46:44+00:00 Ray wrote: we don't look at ~/.dmrc . GDM now uses the account service to choose default session. Is /var/lib/AccountsService/users getting updated after you choose your session and log in? Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/4 ------------------------------------------------------------------------ On 2011-05-02T22:02:34+00:00 Andrew wrote: After logging in once, GDM "remembers" the session. Unfortunately, if you log in on a different machine in a computer lab or reinstall, it "forgets" the session again. I understand that GDM can't (and shouldn't) write to users' home directories, but it should at least be reading the file in the home directories and honoring their explicit configuration. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/5 ------------------------------------------------------------------------ On 2011-06-21T15:31:44+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/6 ------------------------------------------------------------------------ On 2011-06-21T15:33:46+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/7 ------------------------------------------------------------------------ On 2011-06-21T15:36:33+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/8 ------------------------------------------------------------------------ On 2011-06-21T15:39:47+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/9 ------------------------------------------------------------------------ On 2011-06-21T15:49:13+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/10 ------------------------------------------------------------------------ On 2011-06-21T15:51:45+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/11 ------------------------------------------------------------------------ On 2011-06-21T15:54:16+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/12 ------------------------------------------------------------------------ On 2011-06-21T15:55:24+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/13 ------------------------------------------------------------------------ On 2011-08-30T02:10:36+00:00 Elliott wrote: I agree that it would be very nice to be able to specify this from a user's home directory. We have many Fedora machines in lab settings with NFS shared home directories. As it currently is, our only option is to have users select their default session each time they log into a different machine or else set up an NFS share just for /var/lib/AccountService/users. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/14 ------------------------------------------------------------------------ On 2011-09-11T09:47:33+00:00 Ian wrote: I had to switch to kdm due to this problem on FC14 where gdm intermittently forgot the session type. Under FC15 gdm seems to always use gnome by default regardless of previous use. Can't see any selinux denies related to this. Switching to kdm on FC15 pays again; it just works. I agree with Elliot; the setting must come from the user's home directory not some local area elsewhere, otherwise our call center staff will go nuts when they login on a different PC. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/15 ------------------------------------------------------------------------ On 2011-09-21T12:01:08+00:00 Ian wrote: Here's a really horrid hack to make it ignore the default selection of GNOME on F15 and use user-script instead. Ensure your bash scripts place $HOME/bin in your PATH, then ln -s /usr/libexec/xinit-compat $HOME/bin/gnome-session Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/16 ------------------------------------------------------------------------ On 2011-11-25T21:42:28+00:00 Konstantin wrote: Fedora 16, gdm 1:3.2.1.1-8.fc16 When logging in as a user who isn't listed (e.g. user ID below 1000), ~/.dmrc is not used - instead, the system defaults to gnome 3 Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/17 ------------------------------------------------------------------------ On 2011-11-30T19:11:56+00:00 Konstantin wrote: Actually, nevermind. I'll just use LXDM from now on Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/19 ------------------------------------------------------------------------ On 2012-01-19T16:22:54+00:00 Christopher wrote: This is a real pain in the neck. We use NIS for login, with quite a few user IDs below 1000. It would be a major impact to change all the uids, but it's possible (though a major PITA) to change to KDM on each install. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/23 ------------------------------------------------------------------------ On 2012-01-19T16:45:01+00:00 Andrew wrote: (In reply to comment #19) > This is a real pain in the neck. We use NIS for login, with quite a few user > IDs below 1000. It would be a major impact to change all the uids, but it's > possible (though a major PITA) to change to KDM on each install. I haven't noticed ~/.dmrc being used for any users, regardless of UID. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/24 ------------------------------------------------------------------------ On 2012-01-19T17:14:18+00:00 Christopher wrote: And /var/lib/AccountsService/users doesn't appear to be updated, either. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/25 ------------------------------------------------------------------------ On 2012-08-07T19:40:41+00:00 Fedora wrote: This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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 Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/30 ------------------------------------------------------------------------ On 2012-08-08T03:37:18+00:00 Elliott wrote: Although GDM now remembers a user's previous desktop manager in Fedora 16 and 17 it still does not recognize ~/.dmrc or any other config file in a user's home directory. This is a problem for distributed environments that use NFS shared home directories since a user has to select their desktop manager at each new machine. We have roughly 300 lab machines running Fedora and our users often complain that they accidentally forget to change their desktop manager at login, causing them to have to log in and out twice. Maybe it is a feature request at this point but I kinda wish this bug would remain open on Fedora 17. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/31 ------------------------------------------------------------------------ On 2013-04-03T20:15:28+00:00 Fedora wrote: This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/32 ------------------------------------------------------------------------ On 2013-05-31T02:32:33+00:00 Matthias wrote: Lets close this. It is intentional that gdm is not touching the home directory. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/33 ------------------------------------------------------------------------ On 2013-05-31T02:44:53+00:00 Ian wrote: What solution do you propose to cater for the NFS mounted home directory case? Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/34 ------------------------------------------------------------------------ On 2013-05-31T03:17:36+00:00 Andrew wrote: (In reply to Matthias Clasen from comment #25) > Lets close this. It is intentional that gdm is not touching the home > directory. Even if gdm doesn't touch the home directory, it would be a start to at least read from it. (In reply to Ian Donaldson from comment #26) > What solution do you propose to cater for the NFS mounted home directory > case? Indeed. There doesn't seem to be any proposed solution. But what can you expect to work when you use GNOME? :( Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/35 ------------------------------------------------------------------------ On 2013-05-31T05:31:31+00:00 Christopher wrote: (In reply to Matthias Clasen from comment #25) > Lets close this. It is intentional that gdm is not touching the home > directory. I believe the only possible answer to this is: What. The. Fuck. Are. You. Smoking? You're deliberately ignoring what the user wants to do? I presume there is some rationale behind this other than "Hey, let's just make it a royal pain in the butt for people to use anything but GNOME! After all, that's worked so well for Microsoft!" but to be honest, whatever that reason might be, it's not exactly obvious to the casual observer. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/36 ------------------------------------------------------------------------ On 2013-05-31T05:59:18+00:00 John wrote: (In reply to Matthias Clasen from comment #25) > Lets close this. It is intentional that gdm is not touching the home > directory. Dear Matthias, I do not think that closing this bug is the proper way to handle it. I am not sure whether you are away of the original rationale behind the .dmrc file but there is a actually a very important one which is for the user being able to store the settings about the default session and language in a networked environment. Many users, especially paying RedHat customers, are using gdm in a networked environment with homes shared over NFS and people not having a dedicated desktop computer. This means, they need a machine-independent way to store these settings, storing them in a /var subdirectory is completely useless in this setup. If you decide to completely ignore this very important use case, it's your decision. However, since many users need gdm to work in that way, I am predicting more shifts away from GNOME or gdm in the future or one of RedHat's strategic customers writing a complaint (just look at GNOME bug #637095 plus the asssociated RH bugs #561904 and #902448) in the future so that you *have* to reopen and fix the bug. Remember, this is a feature enterprise customers need and use and by removing it, you are deliberately making their lifes harder. Remember, it were actually actions like these from your side which made people fork GNOME and come up with alternatives like MATE. Please consider reopening this bug, it's a mandatory feature in networked environments! Adrian Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/37 ------------------------------------------------------------------------ On 2013-05-31T08:58:07+00:00 Elliott wrote: I agree that this bug should not be closed. NFS mounted home directories are very common and, as it stands, users in such environments that choose not to use GNOME have to specify this every time they log in to a different machine. This is the case for Fedora as well as RedHat environments. For example, I work in a university setting that uses Fedora extensively. Having NFS mounted home directories is ideal. This way a student can log in to any lab machine and work on their homework or research. People find it extremely bothersome to have to select their session at every login, imagine the cumulative time wasted clicking that menu. Why would GDM deliberately avoid reading a user's preferences from their home directory? That makes no sense. After all, it is a user setting. There should be some mechanism for a user to select their default session. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/38 ------------------------------------------------------------------------ On 2013-05-31T13:09:58+00:00 Matthias wrote: You don't have to specify your default session every time you log in. gdm saves it outside the users home directory (in /var/lib/AccountsService/users/). At the worst, you have to choose a session the very first time you log in on a different machine. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/39 ------------------------------------------------------------------------ On 2013-05-31T13:12:34+00:00 Ian wrote: And if you have a room with 100 machines in it and you sit at a different desk nearly every day? Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/40 ------------------------------------------------------------------------ On 2013-05-31T13:22:19+00:00 John wrote: (In reply to Matthias Clasen from comment #31) > At the worst, you have to choose a session > the very first time you log in on a different machine. Well, we have around 50 machines in the students' computer pool at our physics department which means in the worst case students will have manually restore their choice 50 times. There are even more machines in larger departments at this university, so this number can be even higher. Don't you agree that this is quite annoying, especially when the original design of the display manager perfectly solved this by storing this information in the user's home directory? It's a user-specific setting, what exactly is the reasoning to store it outside the home directory in a local path? Adrian Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/41 ------------------------------------------------------------------------ On 2013-05-31T13:25:35+00:00 Matthias wrote: > It's a user-specific setting, what exactly is the reasoning to store it > outside the home directory in a local path? The reason is that the setting is needed outside the session, when it can't be guaranteed that the home directory exists (eg automount). Your password is user-specific too, and isn't stored in your home directory for more or less the same reason. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/42 ------------------------------------------------------------------------ On 2013-05-31T13:28:26+00:00 Rex wrote: I'm sure accountsservice (or possibly sssd if it replaces it someday as threatened in http://www.freedesktop.org/wiki/Software/AccountsService/ ) could be taught to learn about network homes or network-wide settings. Arguing for such in fedora's downstream bugzilla, however, is likely not a good way to facilitate making that happen. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/43 ------------------------------------------------------------------------ On 2013-05-31T13:36:22+00:00 John wrote: (In reply to Matthias Clasen from comment #34) > The reason is that the setting is needed outside the session, when it can't > be guaranteed that the home directory exists (eg automount). Your password > is user-specific too, and isn't stored in your home directory for more or > less the same reason. Well, for one thing, if your home directory is on an automount it will be automatically mounted once the file is accessed, be it through systemd or autofs. It has been worked in the past without any problems, so I don't see why it should be a problem now. As for the password, yes, it is not stored in your home directory. However, the password isn't stored locally either. It is retrieved and verified through NIS or similar services and therefore globally available and modifiable independent of the machine you are using. Your example actually is rather backing up my point than yours. I'd be fine with dropping the .dmrc mechanism if there was an alternative mechanism to retrieve the sesssion information globally over the network, but there isn't which is really unfortunate. Just imagine, if someone, for whatever reason decides to change their default session another time (I tend to be switching desktops/window maangers in the past quite often). They will have to go through this process over and over again. Adrian Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/44 ------------------------------------------------------------------------ On 2013-05-31T13:42:54+00:00 John wrote: (In reply to Rex Dieter from comment #35) > I'm sure accountsservice (or possibly sssd if it replaces it someday as > threatened in http://www.freedesktop.org/wiki/Software/AccountsService/ ) > could be taught to learn about network homes or network-wide settings. Yes, we were actually proposing that during lunch today. However, the mechanism isn't there yet, so it isn't a good thing to remove the .dmrc mechanism first. I honestly expect a complaint from a paying RHEL customer in the future like it happened with the gvfsd issue. The problem was absolutely analogous, GNOME developers not taking special precautions for networked environments which are the dominant form deployed by enterprise customers. The University of Oslo is deploying RHEL 5.x and 6.x on a huge amount of desktop machines. I do not think that it will take very long until someone there sends in a complaint to RedHat. Adrian Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/45 ------------------------------------------------------------------------ On 2013-05-31T13:50:37+00:00 Elliott wrote: > At the worst, you have to choose a session > the very first time you log in on a different machine. We have 300 Fedora machines in our department and they all get re-imaged every 6-months for the next release of Fedora. So, a user could potentially have to select their session 600 times per year :) Besides, they can't be expected to recall which machines they have logged in to. For all practical purposes they have to do it every time. >Arguing for such in fedora's downstream bugzilla, however, is likely not a good >way to facilitate making that happen. There doesn't appear to be an AccountsService mailing list but perhaps it would be better to file a bug report upstream? Between this and the fact that the "user list" feature cannot be disabled, GDM is basically unusable in distributed environments. I suppose we should all just accept this and start using a different session manager or else start contributing to GDM upstream. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/46 ------------------------------------------------------------------------ On 2013-05-31T13:54:19+00:00 Elliott wrote: >The reason is that the setting is needed outside the session, when it can't >be guaranteed that the home directory exists (eg automount). Your password is >user-specific too, and isn't stored in your home directory for more or less >the >same reason. I'm not buying this. If a user's home directory doesn't exist then I don't think they'll care about their default/previous session. If you are referring to automounted home directories then they should get mounted as soon as the file is queried, otherwise they are not going to be able to log in anyway. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/47 ------------------------------------------------------------------------ On 2013-05-31T14:02:09+00:00 John wrote: (In reply to Elliott Forney from comment #38) > Between this and the fact that the "user list" feature cannot be disabled, > GDM is basically unusable in distributed environments. I suppose we should > all just accept this and start using a different session manager or else > start contributing to GDM upstream. Unfortunately, this functionality has only a half-baked implementation in lightdm, it restores only parts of the session information from .dmrc: > https://bugs.launchpad.net/lightdm/+bug/1069494 > https://bugs.launchpad.net/lightdm/+bug/1068853 > https://bugs.launchpad.net/lightdm/+bug/1019314 So, until all of these bugs are fixed, lightdm isn't a viable alternative either. What we did was actually using a fork of gdm 2.20 and deployed it on our Debian Wheezy machines which uses gdm3 by default. This way, we also get the themes functionality back and the display manager works as expected. Adrian Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/48 ------------------------------------------------------------------------ On 2013-10-21T20:59:12+00:00 Adam wrote: What is the next thing to gnome is going to "solve"? Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/49 ------------------------------------------------------------------------ On 2015-03-31T20:11:00+00:00 John wrote: Just a short heads-up on this. Apparently, a paying RedHat customer also made a complaint regarding this issue and Ray Strode actually implemented a workaround for RHEL6 [1]. I am expecting another paying RHEL7 customer to file another bug against gdm3 in the not so distant future meaning that the GNOME developers will actually have to fix the issue for good. I am pretty confident for this to happen as it did previously with a serious gvfs issue that was constantly hammering NFS servers. GNOME developers ignored the issue for several months or even years, then a paying "strategic" customer filed a complaint which got the whole thing escalated and the bug was fixed within two weeks. It's a bit of a pity that GNOME developers apparently often need directions from the management to not ignore important user requests. Adrian > [1] https://bugzilla.redhat.com/show_bug.cgi?id=795920 Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/50 ------------------------------------------------------------------------ On 2016-10-21T22:15:17+00:00 Derek wrote: Our current work around is to use the command: gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User"$(id -u)" --method org.freedesktop.Accounts.User.SetXSession "1-kde-plasma-standard" Even though this isn't as clean as executing ~/.xsession (RHEL5) or reading ~/.dmrc (RHEL6) it does allow you some type of automation when selecting a different session value when logging in at a console. Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/51 ------------------------------------------------------------------------ On 2016-10-21T23:31:30+00:00 Ian wrote: And does that work for the user if they sit at a different machine (in a lab of 50) the next day? Reply at: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/comments/52 ** Changed in: accountsservice (Fedora) Status: Unknown => Won't Fix ** Changed in: accountsservice (Fedora) Importance: Unknown => Medium ** Bug watch added: Red Hat Bugzilla #795920 https://bugzilla.redhat.com/show_bug.cgi?id=795920 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/897212 Title: lightdm ignores session selection of ldap users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
