Description of problem: After upgrading to Fedora-24 (via upgrade), I can no longer login remotely (using XRDP) to a MATE session. The problem occurs AFTER authentication while trying to bring up the desktop - I get a dialog that says "Could not acquire name on session bus" on top of an all black screen (with no visible cursor). If click wildly while moving the mouse, eventually it hit the "Close" part of the dialog, but still no progress on starting the MATE desktop. NOTE: If I change my default desktop in /etc/sysconfig/desktop back to GNOME, the desktop does launch. But then I am stuck with GNOME which is not suitable for my needs :-( Version-Release number of selected component (if applicable): kernel = 4.7.5-200.fc24.x86_64 xrdp = xrdp-0.9.0-5.fc24.x86_64 How reproducible: Totally Steps to Reproduce: 1. Attempt to login to F24 (MATE session) from Win10 RDP client 2. Authenticate 3. Fail with "Could not acquire name on session bus"
After some digging, I found two things of interest (a CLUE and a WORKAROUND) 1) Interestingly, I CAN successfully launch a desktop as root. That seems like an interesting clue (permissions perhaps?) 2) I found some OLD (several years old) Ubuntu references which suggested unsetting "DBUS_SESSION_BUS_ADDRESS" for this error message. I tried that in /etc/sysconfig/desktop and to my amazement that works. This suggests that the GNOME startup scripts may be doing something different than the MATE startup scripts in this regard. So this is an interesting WORKAROUND (for me at least) until the underlying issue is resolved. The fact that MATE has an issue and GNOME doesn't is surely another clue. Either MATE has regressed in F24, or something else has changed that for some reason only affects MATE. No doubt this is related to the WORKAROUND involving unsetting DBUS_SESSION_BUS_ADDRESS
Hmmm - this sounds like it may be related - https://bugzilla.redhat.com/show_bug.cgi?id=1350004
yeah, I don't think its a xrdp bug,
Hey wait a minute - it may not be an XRDP bug, but it surely is a bug. If you think the reported component is wrong, please reassign it to the component you think is faulty, NOT just close it. Thanks in advance for your understanding.
As discussed in the previous comment, could you please help me to figure out what the proper component to report this problem against is? I have just installed Fedora 28 (MATE spin) and ran into the problem again.
Still a problem in Fedora-29
I can get Mate up just fine if I give it a custom DefaultWindowManager script where DBUS_SESSION_BUS_ADDRESS is unset just before calling startwm .sh and with /etc/sysconfig/desktop having DESKTOP=MATE. Authentication was set to password-auth in pam.d file.
In fact, it even works without that variable being unset, as long as there is no other session running for the same user. And gdm auth in pam config works too.
Thanks for the additional workaround! Could you clarify what exactly you changed in pam.d (which file and which lines?).
A couple of clarifications may be helpful here. 1) My original post back in October 2016 failed to mention a critical step in "Steps to Reproduce", namely FIRST login to the console before trying RDP as the same user. I'll post the proper steps to reproduce below. 2) I also posted a workaround in comment 1, similar to comment 7. I'll repost that here too. 3) I created a related ticket, but assigned to component "dbus" (rather than 'xrdp") - see https://bugzilla.redhat.com/show_bug.cgi?id=1452996. WHO SHOULD FIX THIS: Its a bit unclear WHO should be fixing this ticket. Perhaps the "dbus" folks, perhaps the "mate" folks (who don't include a desktop file like some several other desktops do). I'm just trying to keep this ticket alive in enough places that some group actually fixes it so plain old users don't have to muck around with system config files to make something "just work". STEPS TO REPRODUCE (updated with some missing details): 1. Using MATE desktop (I am using the MATE spin) 2 Start a console session for some user 3. Try to create another session for same user via RDP 4. You will get "Could not acquire name on session bus" and attempts to proceed are pretty ineffectual 5. NOTE: if you start the RDP session first, the console login will generally fail with the same DBUS error WORKAROUNDS: 1) Add "unset DBUS_SESSION_BUS_ADDRESS" to /etc/sysconfig/desktop. Apparently some desktops and some other packages do this, but not all (for example not MATE). 2) Alternatively Bojan suggests changing something in pam.d (but I'm not clear exactly what)
I was referring to settings in /etc/pam.d/xrdp-sesman file (from memory). Both sets actually work.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. 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 Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 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 Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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 Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still a bug in Fedora 33.
Cannot replicate this with Xvnc session. Just installed MATE on F33 VM (EC2). Like this: dnf -y --enablerepo=updates-testing update dnf -y --enablerepo=updates-testing install xorgxrp xrdp-selinux dnf -y --enablerepo=updates-testing group install mate echo 'DESKTOP=MATE' /etc/sysconfig/desktop Created user test, gave it a password. Could open a session just fine. With Xorg session, it failed with session bus error. I then added: DESKTOPMANAGER=MATE Into /etc/sysconfig/desktop and tried again. I could get the Xorg session up too. This is based on: https://docs.fedoraproject.org/en-US/quick-docs/switching-desktop-environments/ I do note that sessions in loginctl were not properly cleaned up, but that's likely something to do with MATE itself.
Bojan - Thanks for testing this. However I think you overlooked an aspect of the problem that I did not make clear in the original ticket creation. I did discuss this in more detail in comment #10 but I'm sure it is easy to overlook. To make the problem more clear I just edited the title to append "Could not acquire name on session bus" and have repeated the key part of comment #10 below (NAMELY step 2 to create a console login first). STEPS TO REPRODUCE (updated with some missing details): 1. Using MATE desktop (I am using the MATE spin) 2 Start a console session for some user 3. Try to create another session for same user via RDP 4. You will get "Could not acquire name on session bus" and attempts to proceed are pretty ineffectual 5. NOTE: if you start the RDP session first, the console login will generally fail with the same DBUS error WORKAROUNDS: 1) Add "unset DBUS_SESSION_BUS_ADDRESS" to /etc/sysconfig/desktop. Apparently some desktops and some other packages do this, but not all (for example not MATE). This problem still exists in Fedora-33, and the workaround of "unset DBUS_SESSION_BUS_ADDRESS" is also still effective. I'm not really sure whose problem this is and what component it should be reported against. Do you have any suggestions there? Regards Charlie
AFAICT, this is only a problem with mate desktop. I think you should move this bug there and ask folks that own it, why this is not working.
Just submitted https://bugzilla.redhat.com/show_bug.cgi?id=1928575 agains MATE-DESKTOP
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. 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 Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 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 Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Just leaving update here that it is still exists in fedora 34 I'm unable to login locally with mate till vnc service launched (and xrdp linked to this session). And I'm unable to launch vnc service when local session alive.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 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 Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Fedora 36 still problem exists