Red Hat Bugzilla – Bug 1473806
User cannot log in: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No display available
Last modified: 2017-08-14 04:56:52 EDT
With apologies in advance, this is complicated, may involve more than one bug and/or component, and can't easily be tested because this is on a user's production machine. Summary is: user types username and password into the gdm login box, and his session fails to start and returns him to gdm. If we then switch to VT2 and then back to VT1 then the next login will probably succeed. There are two different failure messages in the logs: 1. systemd: user@12060.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted 2. /usr/libexec/gdm-x-session: (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied) It's this second message that seems to be fixed by the VT switch. But the VT switch doesn't work unless the user has already tried to log in. If we try the VT switch before logging in, then the permission error happens on virtual console 3 instead of 2, and that's the console we now have to switch to in order to fix the error. This machine was running Fedora 24 and was upgraded to Fedora 26 yesterday morning. This wasn't without incident, but we are now at a point where "dnf repoquery --unsatisfied" and "dnf repoquery --duplicated" both say nothing, and "dnf distro-sync" says nothing except about the kernel. I have installed a build of kernel 4.12.0 from Rawhide because the user was experiencing bug 1441906 on a daily basis (but I tried temporarily downgrading the kernel and it didn't fix the problem). In addition, the boot options systemd.legacy_systemd_cgroup_controller=1 and systemd.unified_cgroup_hierarchy=0 are currently being used, because message (1) above led me through a long trail to bug 1435142 where this is suggested, although that might in fact be irrelevant to the current problem. The machine has Intel HD Graphics 530 and initially Xorg was using the "modesetting driver" and gdm was on the default of Wayland, though in the current configuration Xorg is using the "intel" driver and gdm is using Xorg. All kinds of login desktop were tried, mostly Xorg-based but the user was also unable to log in to a Wayland GNOME session. The user who can't log in is a networked user (IPA server + automount home directory) but we have also reproduced the problem with a local user. Currently we have: kernel 4.12.0; legacy cgroups specified on the kernel command line; gdm on Xorg, disable-user-list=true, and the user is logging in with GNOME on Xorg. And SELinux is completely disabled. In this configuration, the workaround described at the top of this bug report is mostly working.
I am currently reproducing this on a fresh F26 install on a VM. However, there appear to be two different issues: 1. Unable to register display with display manager 2. (as noted above) Cannot open virtual console The latter message seems to happen if a login is attempted shortly after the previous login failed, and therefore I think it is a recurrence of Bug 1263208. This may or may not have anything to do with the fact that gnome-keyring-daemon processes owned by the user seem to get left running. But ironically this may also be what helps the user log in after switching VT. Message 1 only seems to affect networked users; a local user can log in straight away when the machine is booted. Message 2 affects both local and networked users.
This appears to be what's causing the "Unable to register display" message: method call time=1501682517.473966 sender=:1.70 -> destination=:1.19 serial=5 path=/org/gnome/DisplayManager/Manager; interface=org.gnome.DisplayManager.Manager; member=RegisterDisplay array [ dict entry( string "session-type" string "x11" ) dict entry( string "x11-display-name" string ":0" ) ] error time=1501682517.474734 sender=:1.19 -> destination=:1.70 error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=5 string "No display available" This happens: - using GDM on Wayland while requesting a GNOME/Xorg session - using GDM on Wayland while requesting a GNOME/Wayland session - using GDM on Xorg while requesting a GNOME/Xorg session (it doesn't seem to be possible to request a GNOME/Wayland session using GDM on Xorg.)
Created attachment 1308407 [details] Debug log of a login failure I'm attaching a debug log showing what GDM does when the login fails. I believe the cause might be this: GdmDisplay: session id: (that is, no session id is printed).
> 1. systemd: user@12060.service: Failed at step PAM spawning > /usr/lib/systemd/systemd: Operation not permitted I guess this is probably the first failure that leads to the other failures. looking in /lib/systemd/system/user@.service I see: PAMName=systemd-user Looking in /etc/pam.d/systemd-user I see: account include system-auth and session include system-auth So, I suppose, you've put something in your /etc/pam.d/system-auth file that's making either the account stack or session stack fail.
OK, not in fact the PAM configuration but the IPA server-side configuration. Adding systemd-user as an allowed service appears to have allowed me to log in first time on the test VM. That was totally non-obvious. Particularly since this denial also happens across all our Fedora 24 machines on which users have always been able to log in first time (and have never reported any problems due to the lack of systemd-user). So I guess this bug is invalid, then. :-/
well it should probably be in the default list, moving to freeipa
Unfortunately I don't have the time at the moment to truly triage the bug, but I'd like to at least point out that there is already https://bugzilla.redhat.com/show_bug.cgi?id=1474899 filed against sssd and it sounds quite like the same or very similar issue.
It's the same, yes (the mention of org.freedesktop.systemd1 in the initial bug report is a red herring).
*** This bug has been marked as a duplicate of bug 1474899 ***