Bug 1795127

Hi Simo,

this might be related to https://pagure.io/SSSD/sssd/issue/4114, can you try SSSD from 8.2 or do you prefer a test build for 8.1?

bye,
Sumit

As long as it installs on 8.1 either wors.
You can also point me at a dist-git tree, then I can build my own packages wth the patches I have to remove the login delay that I have produced a hile back and are on pagure upstream.

Hi Sumit,
I tested with the patches you mentioned.

Now my sssd behaves much better on the slow link (with my additional patches for logged in user speedup), so I believe the patches you gave me already improve the situation. I would go as far as saying they can probably fix this bug too, however I haven't tested yet fully offline logins as I am in meetings all day.

Sounds quite promising though.

Hi Simo,

thanks for the feedback. I will keep this ticket open. Since the patches are already included in the RHEL-8.2 build feel free to close this ticket when your tests are successful.

bye,
Sumit

I have to reract my optimism.
Today I tested an offline situation, I disabled my network cards on the laptop and tried to log in in the VM that is join to IPA.REDHAT.COM using SSSD. The lockscreen prompt never allowed me to set a password, SSSD seem to be stuck trying to resolve my user for some reason.
As soon as I reconnected my ethernet on the laptop the lock screen login prompt unlocked and allowe dme to enter a password.

Also for my other problem it seem the first enthusiasm was a fluke do to short term caching, later on I kept having to wait for some online resolution before a prompt was given.

So it seem the patches were not really useful after all. There must be something in recent SSSD that insists on trying to do something online even when clearly there is no access to the remote server (note that this doesn't mean there is no network, just that there are no routes to reach the server).

Hi,

I'm running a similar setup with recent SSSD which is offline in the sense that the servers cannot be reached quite often and do not see such delays. Please attach SSSD logs with debug_level=9 or send them to me directly.

bye,
Sumit

Hi,

are you using a KDC proxy setup?

bye,
Sumit

No I am using IPA.REDHAT.COM over the VPN.
I also do not see delays right after I boot the machine (and VPN has not been brought up yet).
I generally get stuck when the machine is (or believes to be) on the VPN but the actual underlying network is either very slow or actually gone, but the physical link is still up.

Created attachment 1663588 [details]
level 9 logs

This log was obtain his way:
- sudo -i in the VM
- raise debug_level = 9 in [sssd], [nss], [psm], and the domain section
- restart sssd
- turn off ethernet in the outer host
- lock screen in VM
- back to VM wait at GDM prompt to reauthenticate until GDM, instead, times out never allowing the prompt to ask for a password to be editable
- turn ethernet back on in the outer host
- observe how GDM prompt finally becomes editable requesting a password
- log in
- turn off high level debugging

HTH

Hi Simo,

I'm sorry for the delay, I thought I already pinged you on some other channel.

The logs and the delay make sense because you increased the defaults of ldap_search_timeout, ldap_search_timeout and ldap_opt_timeout from 6, 6, 8 to 15, 15, 15.

Btw, you session detection patches were committed with https://github.com/SSSD/sssd/pull/1005 after fixing some cache_req behavior. They are available in sssd-2.3.0 and hence available in F31 and newer and in the next RHEL-8 release.

bye,
Sumit