Allow for mDNS service/domain/types browsing.
A client can connect to the backend via varlink and receive updates as
the requested service becomes available.
The interval between the first two queries MUST be at least one second,
the intervals between successive queries MUST increase by at least a
factor of two.
When the interval between queries reaches or exceeds 60 minutes, a
querier MAY cap the interval to a maximum of 60 minutes, and perform
subsequent queries at a steady-state rate of one query per hour.
Cache maintenance performed by issuing queries at 80, 85, 90, 95% of the
TTL, and updating/removing the records depending on replies.
TODO:
Improve the DNS transaction logic when multiple clients subscribe to the
same service, ensuring that continuous queries are optimized.
<!-- devel-freezer =
{"comment-id":"1625154850","freezing-tag":"v256-rc2"} -->
Previous implementations had several issues:
- user journals were not updated,
- transition from volatile -> persistent storage transition was not
handled.
Let's make all journal files closed when at least one journal file
related configurations are changed, and reopen necessary journals with
requested settings.
The previous logic was completely broken:
- the access mode comparison is broken,
- flushing kmsg did not work, as the configuration is already disabled,
- seqnum file is not opened when previously disabled,
- failure in reopening /dev/kmsg should not be critical.
This fixes the above issues.
Previously, only config entries controlled by multiple sources were located in
JournalConfig, and still other config entries were in Manager.
That's hard to maintain. Let's move all config entries to JournalConfig.
This also makes JournalConfig.forward_to_kmsg and friends tristate.
Otherwise, even if a higher precedence config source disables the
feature, it may be enabled by a lower precedence config.
As reported in https://github.com/systemd/systemd/issues/38222, we get the
buffer size calculation wrong on 32-bit arm. The reporter suggested checking if
__TIMESIZE == 64, but I think it's better to just use the bigger size in all
cases. The code to guesstimate the buffer size was already tweaked a few times
and apparently it's not easy to get it right. Systemd and glibc might be
compiled with different combinations of __TIMESIZE, so the compile-time check
is not super reliable, and by using the bigger size, we don't depend on the
details of how glibc decided whether to duplicate the struct or not. The cost
is negligible, 16 bytes on stack, so let's do the easy and robust thing.
Solution based on the suggestion by UZver24.
While at it, drop the mock struct definitions. They are only used to calculate
the size, but since the types involved are 8-bit values, there are no alignment
issues and we can just calculate the size directly.
Fixes https://github.com/systemd/systemd/issues/38222.
The comment in linux_exec() was based on Lennart's comment in
https://github.com/systemd/systemd/pull/37372#discussion_r2142340582, but
shortened. The original wording is more direct and at least for me easier to
grok, so adjust the comment to be more verbose again.
Also, move the comment from shim_loader_available() to the place where it used.
This function is for checking if the new thing is available, no need to describe
the old thing there.
This extends the functionality introduced in #21648 to allow using
addresses chosen from a delegated prefix as well as the existing
SLAAC/LL/DHCP functionality.
