On 07. 08. 23 12:49, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 01 August 2023 at 12:16, Petr Menšík wrote:
Hi Pavel,
With Avahi upstream maintainer hat on, I would say it still makes sense to
have separate mdns*_minimal and mdns? modules. I would say mdns
(non-minimal) should be rarely needed, because by default it should be used
just for *.local names. As I have wrote to referenced ticket, I think we
want to prefer mdns_minimal in the future, but it first needs solving
increased timeouts for not present names [1]. As soon as it is solved on
avahi-daemon side, we can deprecate mdns{4,6}_minimal and mdns{4,6}
variants. If only one family should be resolved, I think it would be better
to configure it on side of avahi-daemon.
Simpler is good if it still offers the features required by Fedora.
I think mdns resolution needs smarter approach from avahi-daemon. It might
be useful to not open and re-parse /etc/mdns.allow on every single
``getaddrinfo()`` call, but cache it in thread local storage and re-read its
contents only on timestamp change. Maybe with checking the file stamp only
once per second at most.
Isn't inotify what should be used in such cases?
Regards,
Dominik
inotify is good for such changes, but I would prefer having inotify
socket on side of avahi-daemon. I think inotify sockets are limited and
should not be used by every common client application using nss plugin
for resolution. Let alone by every thread. I think default limit of
inotify sockets is something around 256.
/proc/sys/fs/inotify/max_user_instances gives 128 on my f37. nss plugin
files reads /etc/hosts on every resolution too. I made the change to try
opening /etc/mdns.allow from every call therefore. I am not sure how
critical this file optimization might be.
I haven't found any good way to store cached structures after calls to
getaddrinfo() or getnameinfo(), which would be reasonably safe to use in
simple applications as well as threaded applications. It seems the way
how glibc handles /etc/resolv.conf is not simple to be reused by other
plugins. Cached structures might include allocated memory or any kind of
socket, including inotify. Maybe it is the correct way to rely on
filesystem caching and just call fopen() and fclose() on every name
resolution attempt. That is thread-safe and well supported, is
race-condition free.
res_ninit() call is able to open context for DNS resolution, but that is
available only fro DNS specific resolution. The abstract getaddrinfo()
or getnameinfo() have no way to open cache store on start and clean it
on thread stop or application exit. I think optimizations should be done
only if there is a correct way how to solve them. It seems to me
original nss plugin system does not offer something similar.
Cheers,
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
