Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
systemd-resolved support
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Max Kellermann via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 24 Nov 2023 20:25:05 +0100
Hi,
we recently had a problem with libcurl: due to a DNS server problem,
an attempt to cancel a libcurl request blocked the whole I/O event
loop of a server process because libcurl was waiting for the resolver
thread to finish (inside pthread_join()), causing a major outage of a
service.
We use Debian, and Debian's libcurl build uses the threaded resolver
and not c-ares, and I learned that the threaded resolver cannot be
canceled at all. CURLOPT_QUICK_EXIT is not usable, because this is a
long-running server process.
My idea to work around this is to first let our daemon resolve with
systemd-resolved (which is easy to use and cancellable) and then use
CURLOPT_CONNECT_TO to prevent libcurl from using its own resolver. We
already use systemd-resolved extensively and we have a
non-blocking/cancellable client for it.
For the long term, I was wondering whether libcurl would be interested
in incorporating a systemd-resolved mode if I were to submit a pull
request. It should be possible to switch this on at runtime, or else
distributions won't enable it in their builds and the code will never
be used by anybody.
There could be an option to auto-detect at runtime whether resolved is
available and fall back to the threaded resolver if not; though some
users might prefer to never use resolved even if it is available
because using it will ignore /etc/nsswitch.conf.
What's your opinion on such a feature for libcurl?
Max
Date: Fri, 24 Nov 2023 20:25:05 +0100
Hi,
we recently had a problem with libcurl: due to a DNS server problem,
an attempt to cancel a libcurl request blocked the whole I/O event
loop of a server process because libcurl was waiting for the resolver
thread to finish (inside pthread_join()), causing a major outage of a
service.
We use Debian, and Debian's libcurl build uses the threaded resolver
and not c-ares, and I learned that the threaded resolver cannot be
canceled at all. CURLOPT_QUICK_EXIT is not usable, because this is a
long-running server process.
My idea to work around this is to first let our daemon resolve with
systemd-resolved (which is easy to use and cancellable) and then use
CURLOPT_CONNECT_TO to prevent libcurl from using its own resolver. We
already use systemd-resolved extensively and we have a
non-blocking/cancellable client for it.
For the long term, I was wondering whether libcurl would be interested
in incorporating a systemd-resolved mode if I were to submit a pull
request. It should be possible to switch this on at runtime, or else
distributions won't enable it in their builds and the code will never
be used by anybody.
There could be an option to auto-detect at runtime whether resolved is
available and fall back to the threaded resolver if not; though some
users might prefer to never use resolved even if it is available
because using it will ignore /etc/nsswitch.conf.
What's your opinion on such a feature for libcurl?
Max
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-11-24