[systemd-devel] systemd-resolved: performance question
Petr Menšík
pemensik at redhat.com
Fri Mar 24 11:54:26 UTC 2023
I think it is fairly easy. If the /etc/resolv.conf changes not by a
change of systemd-resolved, it is very likely the address specified in
it does not point to resolved anymore. In that sense it does not matter
what systemd-resolved does with such information and how quickly.
Does it update its own configured forwarders if I overwrite
/etc/resolv.conf with something unspecified in resolved.conf or
resolvectl runtime changes? I have tried appending nameserver 8.8.8.8,
but it has not reported any change in resolvectl. I would not expect a
third party would overwrite /etc/resolv.conf and use address of
systemd-resolved in it. If you know such case, please share. Is there a
real-world example case when such behaviour is needed?
I think resolved can just queue incoming request even from resolve NSS
plugin. If it detects a change in /etc/resolv.conf link, then it can
restart waiting requests again (or after a short timeout, 1s would
work). It would be much better than checking the link state before every
single query. It would conserve CPU work on battery operated devices. I
would set resolv.conf files in /run/systemd/resolved/ immutable to
prevent other software writing into it.
On 3/24/23 11:41, Lennart Poettering wrote:
> On Fr, 24.03.23 03:16, Petr Menšík (pemensik at redhat.com) wrote:
>
>> Even if it could not use filesystem monitoring, I guess it could check those
>> files only once per second or so. Should not depend on number of done
>> queries.
> It's not so easy. We generally want to give the guarantee that if
> people from some script patch around in /etc/resolv.conf and
> immediately fire a DNS request afterwards, that we'll handle this and
> give you answers with the new config.
>
> There are conflicting goals here: nice, reliably behaviour that config
> changes are guaranteed to be taken into account, and a simple goal of
> performance to reduce these stat calls.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
More information about the systemd-devel
mailing list