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.
Re: systemd-resolved support
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Cristian Rodríguez via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 25 Nov 2023 09:32:33 -0300
On Fri, Nov 24, 2023 at 4:36 PM Max Kellermann via curl-library <
curl-library_at_lists.haxx.se> wrote:
> 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.
>
resolved is designed to be spoken to as a normal dns caching resolver or
using dbus.
I don't believe adding a dbus communication backend will improve your
situation.
I tried several years ago to switch opensuse 's curl to use the c-ares
backend , unfortunately it lasted for a brief time until it was reverted
due to the world burning down.
IIRC a bug was never filled or I missed it so I don't know exactly what
broke.
What you describe appears to be just a bug that needs analysis..
Date: Sat, 25 Nov 2023 09:32:33 -0300
On Fri, Nov 24, 2023 at 4:36 PM Max Kellermann via curl-library <
curl-library_at_lists.haxx.se> wrote:
> 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.
>
resolved is designed to be spoken to as a normal dns caching resolver or
using dbus.
I don't believe adding a dbus communication backend will improve your
situation.
I tried several years ago to switch opensuse 's curl to use the c-ares
backend , unfortunately it lasted for a brief time until it was reverted
due to the world burning down.
IIRC a bug was never filled or I missed it so I don't know exactly what
broke.
What you describe appears to be just a bug that needs analysis..
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-11-25