nss-resolve: be a bit more careful with returning NSS_STATUS_NOTFOUND
authorLennart Poettering <lennart@poettering.net>
Mon, 24 Oct 2016 16:50:43 +0000 (18:50 +0200)
committerLennart Poettering <lennart@poettering.net>
Mon, 24 Oct 2016 17:04:43 +0000 (19:04 +0200)
commit344874fcd0a3fc1f9bc6cdf34ecaf537c10a3ad3
tree807dfaafa04b3ae6fe6902f8652f3ccdf9c547d4
parent413b05ccac40a9d53d278a3a17061286ea44e26d
nss-resolve: be a bit more careful with returning NSS_STATUS_NOTFOUND

Let's tighten the cases when our module returns NSS_STATUS_NOTFOUND. Let's do
so only if we actually managed to talk to resolved. In all other cases stick to
NSS_STATUS_UNAVAIL as before, as it clearly indicates that our module or the
system is borked, and the "dns" fallback should really take place.

In particular this fixes the 2nd-level fallback from our own dlopen() based
fallback handling. In this case we really should return UNAVAIL so that the
caller can apply its own fallback still.

Fix-up for d7247512a904f1dd74125859d8da66166c2a6933.

Note that our own dlopen() based fallback is pretty much redundant now if
nsswitch.conf is configured like this:

   hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname

In a future release we should probably drop our internal fallback then, in
favour of this nsswitch.conf-based one.
src/nss-resolve/nss-resolve.c