DNS queries need timeout values to detect whether a DNS server is
unresponsive or, if the query is sent over UDP, whether a DNS message
was lost and has to be resent. The total time that it takes to answer a
query to arrive is t + RTT, where t is the maximum time that the DNS
server that is being queried needs to answer the query.
An authoritative server stores a copy of the zone that it serves in main
memory or secondary storage, so t is very small and therefore the time
that it takes to answer a query is almost entirely determined by the
RTT. Modern authoritative server software keeps its zones in main memory
and, for example, Knot DNS and NSD are able to answer in less than
100 µs [1]. So iterative resolvers continuously measure the RTT to
optimize their query timeouts and to resend queries more quickly if they
are lost.
systemd-resolved is a stub resolver: it forwards DNS queries to an
upstream resolver and waits for an answer. So the time that it takes for
systemd-resolved to answer a query is determined by the RTT and the time
that it takes the upstream resolver to answer the query.
It seems common for iterative resolver software to set a total timeout
for the query. Such total timeout subsumes the timeout of all queries
that the iterative has to make to answer a query. For example, BIND
seems to use a default timeout of 10 s.
At the moment systemd-resolved derives its query timeout entirely from
the RTT and does not consider the query timeout of the upstream
resolver. Therefore it often mistakenly degrades the feature set of its
upstream resolvers if it takes them longer than usual to answer a query.
It has been reported to be a considerable problem in practice, in
particular if DNSSEC=yes. So the query timeout systemd-resolved should
be derived from the timeout of the upstream resolved and the RTT to the
upstream resolver.
At the moment systemd-resolved measures the RTT as the time that it
takes the upstream resolver to answer a query. This clearly leads to
incorrect measurements. In order to correctly measure the RTT
systemd-resolved would have to measure RTT separately and continuously,
for example with a query with an empty question section or a query for
the SOA RR of the root zone so that the upstream resolver would be able
to answer to query without querying another server. However, this
requires significant changes to systemd-resolved. So it seems best to
postpone them until other issues have been addressed and to set the
resend timeout to a fixed value for now.
As mentioned, BIND seems to use a timeout of 10 s, so perhaps 12 s is a
reasonable value that also accounts for common RTT values. If we assume
that the we are going to retry, it could be less. So it should be enough
to set the resend timeout to DNS_TIMEOUT_MAX_USEC as
DNS_SERVER_FEATURE_RETRY_ATTEMPTS * DNS_TIMEOUT_MAX_USEC = 15 s.
However, this will not solve the incorrect feature set degradation and
should be seen as a temporary change until systemd-resolved does
probe the feature set of an upstream resolver independently from the
actual queries.
[1] https://www.knot-dns.cz/benchmark/
Let's always write "1 << 0", "1 << 1" and so on, except where we need
more than 31 flag bits, where we write "UINT64(1) << 0", and so on to force
64bit values.
This new setting is supposed to be useful in most cases where
"MountFlags=slave" is currently used, i.e. as an explicit way to run a
service in its own mount namespace and decouple propagation from all
mounts of the new mount namespace towards the host.
The effect of MountFlags=slave and PrivateMounts=yes is mostly the same,
as both cause a CLONE_NEWNS namespace to be opened, and both will result
in all mounts within it to be mounted MS_SLAVE. The difference is mostly
on the conceptual/philosophical level: configuring the propagation mode
is nothing people should have to think about, in particular as the
matter is not precisely easyto grok. Moreover, MountFlags= allows configuration
of "private" and "slave" modes which don't really make much sense to use
in real-life and are quite confusing. In particular PrivateMounts=private means
mounts made on the host stay pinned for good by the service which is
particularly nasty for removable media mount. And PrivateMounts=shared
is in most ways a NOP when used a alone...
The main technical difference between setting only MountFlags=slave or
only PrivateMounts=yes in a unit file is that the former remounts all
mounts to MS_SLAVE and leaves them there, while that latter remounts
them to MS_SHARED again right after. The latter is generally a nicer
approach, since it disables propagation, while MS_SHARED is afterwards
in effect, which is really nice as that means further namespacing down
the tree will get MS_SHARED logic by default and we unify how
applications see our mounts as we always pass them as MS_SHARED
regardless whether any mount namespacing is used or not.
The effect of PrivateMounts=yes was implied already by all the other
mount namespacing options. With this new option we add an explicit knob
for it, to request it without any other option used as well.
See: #4393
Currently the completion adds template units for commands such as
is-active, is-failed, is-enabled, status, show and others.
At the same time systemctl barfs at us, since an instanced template unit
is needed. Follow the example list from bash-completion as to which
commands should not list template units.
Note: The above is observed regardless of DefaultInstance.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Template units lacking DefaultInstance cannot be enabled/disabled or
started/restarted.
By adding DefaultInstance the unit can be enabled/disabled but it
still cannot be started/restarted.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Earlier patch added the current word to the performance critical paths.
Here we add it to every place, for consistency sake.
Suggested-by: Yu Watanabe (yuwata)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This effectively ports over b1bdb6496c
from the bash completion to zsh.
Modulo the new function, since it's unrelated perf. improvement.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Using a leading * and $SUFFIX produces misleading results. Let's imagine
that one mistypes nect instead of netc, they will get a rather
misleading completion like: sys-fs-fuse-connections.mount
Not to mention that the execution time is up by ~1/3.
time systemctl list-unit-files netctl* -> ~12ms
time systemctl list-unit-files *netctl* -> ~17ms
Furthermore more units are matched, leading to greater execution time
of `systemctl show' in _filter_units_by_property
Use only $PREFIX*, removing the leading * and trailing $SUFFIX*.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Pass the partial name of the unit file to list-unit-files and
list-units. This allows for faster completion, since systemctl does
not need to list all the unit files.
For reference:
- time systemctl list-unit-files -> ~200ms
- time systemctl list-unit-files netctl* -> ~15ms
- time systemctl list-units -> ~5ms
- time systemctl list-units netctl* -> ~5ms
While the list-units time itself is unaffected, now a shorter list is
produced. Thus as we pass it to `systemctl show' (via
__filter_units_by_properties) the execution time will be decreased even
further.
v2: Update list-units hunk in commit message, add quotes around $2*
v3: Remove funky indentation, quote all $cur instances
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Lennart Poettering