[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