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
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: email@example.com: 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
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
error time=1501682517.474734 sender=:1.19 -> destination=:1.70 error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=5
string "No display available"
- 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: firstname.lastname@example.org: 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:
Looking in /etc/pam.d/systemd-user I see:
account include system-auth
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
*** This bug has been marked as a duplicate of bug 1474899 ***