Description of problem: gdm makes metacity run (as user "gdm") in the logged-in session, preventing a different window manager from starting. kdm does not have this problem. Version-Release number of selected component (if applicable): Cauldron. How reproducible: Always. Steps to Reproduce: 1. Set gdm as your display manager. 2. Login to a new LXDE session 3. In a terminal type "ps auxwwwwwwwwwwwww | grep metacity".
Summary: gdm makes metacity runs in the logged-in session, preventing a different window manager from starting. => gdm makes metacity run in the logged-in session, preventing a different window manager from starting.
CC: (none) => dmorganec, fundawang, mageia
I should note that there's a similar report on Ubuntu's launchpad: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/822253 Regards, -- Shlomi Fish
Is this with the latest gdm? It does things quite differently to previously (including not running metacity). I know the SRPM is set to the latest version, but the Launchpad bug predates these changes in gdm, so I just want to be certain.
(In reply to comment #2) > Is this with the latest gdm? It does things quite differently to previously > (including not running metacity). > > I know the SRPM is set to the latest version, but the Launchpad bug predates > these changes in gdm, so I just want to be certain. shlomif@lap:~$ rpm -q gdm gdm-3.1.90-1.mga2 I should note that I don't recall encountering this problem in the older "gdm" before the upgrade, but on the other hand, I stayed on the same open KDE session for quite a few days. Regards, -- Shlomi Fish
I recently discoverd gdm behavior was different when using systemd and classical sysinit. Colin explained this was probably due to DRI permissions issues in the second case.
CC: (none) => guillomovitch
This is likely a permissions issue. I'm not sure that gdm is registering itself with console-kit any more and thus does not get permissions on the gdm device. Or perhaps it just registers itself too later for the check? Either way, it should work fine with systemd. This is pretty much what upstream are targeting these days anyway. If you want to check, login via the tty when GDM is waiting, and type: "sleep 5; ck-list-sessions; getfacl /dev/dri/card0", then switch back to GDM, wait 10 seconds or so and switch back. If the gdm user is listed and has ACL access to the DRI card then all is well with consolekit registration, but if not, then this is the fundamental problem. if it is listed than it's likely a race - e.g. console-kit didn't apply the ACLs quickly enough for the check to happen. You should also check for .rpmnew files in /etc/pam.d/ These files are listed as config(noreplace) in the spec but IMO this is a bad idea as things pretty much WILL break if we need to change things later (as is the case just now)
OK, can you try this: Can you edit and add the line: /etc/pam.d/gdm-welcome -session optional pam_ck_connector.so BEFORE the line: session include system-auth And then reboot... see if that helps?
(In reply to comment #6) > OK, can you try this: > > Can you edit and add the line: /etc/pam.d/gdm-welcome > > -session optional pam_ck_connector.so > This line contains a leading "-", but all the other lines on the file don't. What is the correct form? Regards, -- Shlomi Fish > BEFORE the line: > > session include system-auth > > And then reboot... see if that helps?
Said on IRC but for completeness, the - at the beginning of a line means "do not fail if the module is not installed".
(In reply to comment #6) > OK, can you try this: > > Can you edit and add the line: /etc/pam.d/gdm-welcome > > -session optional pam_ck_connector.so > > BEFORE the line: > > session include system-auth > > And then reboot... see if that helps? OK, I've added this line to the file. My /etc/pam.d/gdm-welcome file looks like this, now: [Q] #%PAM-1.0 auth required pam_env.so auth required pam_permit.so account required pam_nologin.so account include system-auth password include system-auth session required pam_loginuid.so session optional pam_keyinit.so force revoke -session optional pam_ck_connector.so session include system-auth [/Q] However, after rebooting and starting gdm and selecting an LXDE session, metacity is still running as user gdm. Regards, -- Shlomi Fish
It would be more interesting to see the output from the commands I've listed previously as was reported by JA Magallon on the mailing list. That said, I suspect now that this will be insufficient anyway. I'll have to look at the gdm code to see whether they totally ripped out CK registration or not.
Actually I've just been informed that there was a bug in the last GDM that prevented the consolekit registration from working. So the support has not yet been removed - it's just buggy. This will be fixed in the next GDM.
I'm trying to figure out this perm issue also. Why are they 5 different PAM configuration files for gdm now, and an additional 'gdm-password' symlink ?
I should note that I'm using sysinit and not systemd.
@Shlomi, yes. The issue was related to Console Kit permissions in the latest GDM package which is only really relevant with sysvinit, not systemd. @Guillaume: yeah it's a bit of a headfuk. I think the plain "gdm" one can basically be deprecated now as this isn't used any more (it falls back to it in some circumstances from my brief read of the code, but I think only if gdm-password does not exist) The other gdm related configs are for complex use cases (e.g. fingerprint scanners and the like) of which I have pretty much zero clue!
(In reply to comment #11) > Actually I've just been informed that there was a bug in the last GDM that > prevented the consolekit registration from working. So the support has not yet > been removed - it's just buggy. This will be fixed in the next GDM. This bug was filed against gdm-3.1.90-1.mga2.src.rpm Current version is gdm-3.2.1.1-1.mga2.src.rpm Is this bug still valid? If so, should it be marked "UPSTREAM" and is there an upstream report to link to?
Keywords: (none) => NEEDINFOCC: (none) => marja11
(In reply to comment #15) > (In reply to comment #11) > > Actually I've just been informed that there was a bug in the last GDM that > > prevented the consolekit registration from working. So the support has not yet > > been removed - it's just buggy. This will be fixed in the next GDM. > > This bug was filed against gdm-3.1.90-1.mga2.src.rpm > Current version is gdm-y.2.1.1-1.mga2.src.rpm > > Is this bug still valid? > If so, should it be marked "UPSTREAM" and is there an upstream report to link > to? Apparently, this bug was fixed - I tested with both systemd and sysvinit, and could not reproduce it anymore in either of them. So I'm closing it. (Note that I'm on an x86-64 machine instead of an i586 now.).
Status: NEW => RESOLVEDResolution: (none) => FIXED