Rebuild gdm #513
Merged
Rebuild gdm #513
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This patch is not needed. To enable gdm debugging, add
[debug]
Enable=true
to /etc/gdm/custom.conf .
The patch works around a problem which sometimes froze gdm after entering the password. It depends on timing with nis and the number of users. Patch description: From: Donald Buczek <buczek@molgen.mpg.de> Date: Tue, 17 Oct 2017 12:38:25 +0200 Subject: [PATCH] GdmSessionWorker: Wait for ActUserManager We implicitly access the (singleton) ActUserManager via GdmSessionSettings. ActUserManager provided by libaccountsservice does asynchronous method invocations via dbus to the account service daemon (accountsdaemon.service). Depending on the number of users and the definition of the user database (which may involve rpc calls in the NIS case), the response to the ListCachedUsers call may take an undefined amount of time. We need to execute our main loop to get the responses for the asynchronous method invocations processed and delivered to ActUserManager. However, the current implementation of the pam services does synchronous method calls over the dbus and we don't return to our main loop while we are waiting for the user to enter the username or the password. If ActUserManger didn't complete its setup before we get into that state and the user needs longer then a dbus specific timeout (several seconds) to enter his data, the dbus daemon will delete the reply and the login process doesn't complete. The fix here is to check that ActUserManager has completed its setup before we switch to the states involving pam.
Sign in
to join this conversation on GitHub.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds a patch to wors around a problem which sometimes froze gdm after
entering the password. It depends on timing with nis and the number of
users.
Removed debugging.
Patch description:
From: Donald Buczek buczek@molgen.mpg.de
Date: Tue, 17 Oct 2017 12:38:25 +0200
Subject: [PATCH] GdmSessionWorker: Wait for ActUserManager
We implicitly access the (singleton) ActUserManager via
GdmSessionSettings.
ActUserManager provided by libaccountsservice does asynchronous
method invocations via dbus to the account service daemon
(accountsdaemon.service). Depending on the number of users and the
definition of the user database (which may involve rpc calls in the
NIS case), the response to the ListCachedUsers call may take an
undefined amount of time.
We need to execute our main loop to get the responses for the
asynchronous method invocations processed and delivered to
ActUserManager.
However, the current implementation of the pam services does synchronous
method calls over the dbus and we don't return to our main loop while we
are waiting for the user to enter the username or the password. If
ActUserManger didn't complete its setup before we get into that state
and the user needs longer then a dbus specific timeout (several
seconds) to enter his data, the dbus daemon will delete the reply and
the login process doesn't complete.
The fix here is to check that ActUserManager has completed its setup
before we switch to the states involving pam.