Some testresults:
resolv.conf dns server*, nsswitch setting, hosts contains 127.0.1.1 entry, result
---------------------------------------------------------------------------------
127.0.0.53 , file resolve dns, no , fails
127.0.1.1 , file resolve dns, no , fails
127.0.0.53 , file dns , no , works
127.0.1.1 , file dns , no , works
127.0.0.53 , file resolve dns, yes , works
127.0.1.1 , file resolve dns, yes , works
* if 127.0.0.53, symlink to /lib/systemd/resolve.conf is in use
Conclusion: the problem is in nss_resolve
since nss_resolve should use dbus, I checked with dbus-monitor --system what is sent.
If you are able to reproduce this problem: To me it seems that the request is sent after the timeout already happened. Also while the login attempt is running, systemd-resolve is not working. Do you know a situation dbus-daemon is blocking?. If this proves true, what could cause this?
Some testresults: ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ----
resolv.conf dns server*, nsswitch setting, hosts contains 127.0.1.1 entry, result
-------
127.0.0.53 , file resolve dns, no , fails
127.0.1.1 , file resolve dns, no , fails
127.0.0.53 , file dns , no , works
127.0.1.1 , file dns , no , works
127.0.0.53 , file resolve dns, yes , works
127.0.1.1 , file resolve dns, yes , works
* if 127.0.0.53, symlink to /lib/systemd/ resolve. conf is in use
Conclusion: the problem is in nss_resolve
since nss_resolve should use dbus, I checked with dbus-monitor --system what is sent.
If you are able to reproduce this problem: To me it seems that the request is sent after the timeout already happened. Also while the login attempt is running, systemd-resolve is not working. Do you know a situation dbus-daemon is blocking?. If this proves true, what could cause this?